Subject: Re: dev/audiobell.c proposal
To: None <mouse@Rodents.Montreal.QC.CA>
From: Ben Harris <bjh21@netbsd.org>
List: tech-kern
Date: 01/11/2004 15:09:18
In article <200401110511.AAA08205@Sparkle.Rodents.Montreal.QC.CA> you write:
>Then we really need an audio-device analogue to tun(4) or pty(4), so
>that the mixer can get at the output generated by the chat program or
>console bell or whatever, to mix it in with whatever else.
>
>Also needed would be a way to direct console beeps to a specific audio
>device, or else some other way to direct them to userland for the
>actual beep generation to be handled there.
For added fun, there can be several wsdisplay/wskbd combinations on a
machine, and each one needs to be able to send its bells to a different
place. This is beginning to sound to me like the right approach would be a
wsbell device to go alongside wskbd and wsdisplay, being attached to
wsdisplay in much the same way as wskbd is. In fact, just implementing a
bell as a wskbd that sends no events and only responds to
WSKBDIO_COMPLEXBELL would probably work quite nicely, albeit causing
horrible user confusion ("wskbd at audio? wtf??"). Redirecting bells to
userland would then be kind of the inverse of what moused does.
FWIW, I think that user processes that grab bell output should get (freq,
length, volume) rather than a waveform, in the same way that TIOCCONS gets
you characters, not a pixmap of the console screen.
--
Ben Harris <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26 <URL:http://www.NetBSD.org/Ports/acorn26/>