Re: [patch 1/1] pc-speaker: add SND_SILENT

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Bodo Eggert]

Stas Sergeev <stsp@aknet.ru> wrote:

> [ adding LKML to CC and removing akpm as this went into a
> discussion phase apparently ]
> 
> Dmitry Torokhov wrote:

>>> Well, the main reason behind that change, is that there is a PC-Speaker
>>> PCM driver/emulator, snd-pcsp, pending in an ALSA CVS. I can't get it
>>> included in kernel before there is a way to disable the pcspkr driver.
>> Why can't you? We have ALSA and OSS together in the kernel just fine.
> But the pcspkr driver is not an OSS, it is an "input" driver.
> 
>> If you are concerned about both modules baing active at the same time
>> do not let user compile pcspkr if snd_pcsp is selected for now.
> The problem is that the snd-pcsp doesn't replace pcspkr.

If that's the problem, create a minimal input driver that will signal the
snd-pcsp to beep, and change the original pcspkr to include "(Non-ALSA)".
Obviously both drivers will exclude each other, but that should be fine,
and users who prefer "music" over beeps will be fine, too.

And as a bonus, you might upload a custom PC beep ... but if you do, a
userspace notifyer combined with a beep-daemon might be preferable
(uinput? I know it exists ...).

Off cause I might be suggesting exactly what you did, since I didn't see
the patch.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hello.

Bodo Eggert wrote:
>> The problem is that the snd-pcsp doesn't replace pcspkr.
> If that's the problem, create a minimal input driver that will signal the
> snd-pcsp to beep, and change the original pcspkr to include "(Non-ALSA)".
Yes, making snd-pcsp to produce the console beeps and
making it mutually exclusive with pcspkr is possible.
But I think it is undesireable. People that don't like
the console beeps (myself included) simply do not load
the pcspkr module right now. If snd-pcsp is to produce
the beeps, then not loading pcspkr will not get the desired
effect any more, and the only possibility would be to,
probably, add the separate mixer control for the beeps.
I find this counter-intuitive: some people will be able to
disable the beeps by simply not loading pcspkr, while for
others this will suddenly magically stop working. This may
lead to a few unnecessary bug reports and confusions.

I think I'd better try to code up the grabbing capability in
the input layer, since Dmitry didn't seem to object to that.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Bodo Eggert]

On Sun, 26 Mar 2006, Stas Sergeev wrote:
> Bodo Eggert wrote:

> >> The problem is that the snd-pcsp doesn't replace pcspkr.
> > If that's the problem, create a minimal input driver that will signal the
> > snd-pcsp to beep, and change the original pcspkr to include "(Non-ALSA)".

> Yes, making snd-pcsp to produce the console beeps and
> making it mutually exclusive with pcspkr is possible.
> But I think it is undesireable. People that don't like
> the console beeps (myself included) simply do not load
> the pcspkr module right now. If snd-pcsp is to produce
> the beeps, then not loading pcspkr will not get the desired
> effect any more, and the only possibility would be to,
> probably, add the separate mixer control for the beeps.

I asumed the input driver would be an extra module. Otherwise it should at 
least be a runtime option (off cause).
-- 
Microwave: Signal from a friendly micro... 

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Jan Engelhardt]

>>> The problem is that the snd-pcsp doesn't replace pcspkr.
>>>
>> If that's the problem, create a minimal input driver that will signal the
>> snd-pcsp to beep, and change the original pcspkr to include "(Non-ALSA)".
>>
> Yes, making snd-pcsp to produce the console beeps and
> making it mutually exclusive with pcspkr is possible.
> But I think it is undesireable. People that don't like
> the console beeps (myself included) simply do not load

I like the current approach, that is, load pcspkr to get a beep, load 
pcspkr+snd-pcsp to get the full blow.

On some servers, I need a mixture of when to allow a beep and when not. In 
these, I patched the oops and panic functions to make a sound, which 
implies that pcspkr.ko must be loaded. In turn, I modified vt.c to have the 
default bell time = 0 to shut /bin/*sh up. Works good.


Jan Engelhardt
-- 

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Kyle Moffett]

On Mar 26, 2006, at 13:46:24, Jan Engelhardt wrote:
> I like the current approach, that is, load pcspkr to get a beep,  
> load pcspkr+snd-pcsp to get the full blow.
>
> On some servers, I need a mixture of when to allow a beep and when  
> not. In these, I patched the oops and panic functions to make a  
> sound, which implies that pcspkr.ko must be loaded. In turn, I  
> modified vt.c to have the default bell time = 0 to shut /bin/*sh  
> up. Works good.

In a lab I used to run we had a bunch of Linux workstations where  
some users tended to abuse the console beeper.  Our solution was a  
small kernel patch to add a CAP_VT_BEEP which was checked in the  
various console functions before generating a sound or modifying the  
default beep settings.  This allowed our automated hourly chimes to  
run without interference (run from cron as root), while preventing  
users not in the audio group from making sounds (/usr/bin/beep was  
root:audio 04750).

Cheers,
Kyle Moffett

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Dmitry Torokhov]

On 3/26/06, Stas Sergeev <stsp@aknet.ru> wrote:
>
> I think I'd better try to code up the grabbing capability in
> the input layer, since Dmitry didn't seem to object to that.
>

I was pondering over implications of "grabbing" events over the
weekend and I am not entirely happy with it either. The problem with
grabbing is that your driver does not have any knowledge of how the
events would be processed if left untouched. Right now you assume that
all bells are handled by pcspkr but we could really have alternative
bell implementations. For example we could have "visual" bell that
could flash framebuffer or a bell that is routed through ALSA, etc,
etc. All these alternative bells would not disrupt operation of your
snd_pcsp module but it still would disable the bell because it does
not know better.

--
Dmitry

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hi.

Dmitry Torokhov wrote:
>> I think I'd better try to code up the grabbing capability in
>> the input layer, since Dmitry didn't seem to object to that.
> I was pondering over implications of "grabbing" events over the
> weekend and I am not entirely happy with it either. The problem with
> grabbing is that your driver does not have any knowledge of how the
> events would be processed if left untouched. Right now you assume that
> all bells are handled by pcspkr but we could really have alternative
> bell implementations. For example we could have "visual" bell that
> could flash framebuffer or a bell that is routed through ALSA, etc,
> etc. All these alternative bells would not disrupt operation of your
> snd_pcsp module but it still would disable the bell because it does
> not know better.
Why not? I can check dev.id.bustype and dev.phys to find out what
exactly resources it allocates. This all is present in "struct input_dev"
AFAICS. And since they are here, I don't agree using the input subsystem
on that layer is completely wrong.
Well, I can also add the hack to snd-pcsp to always reprogram PIT
chan 2 to proper mode in an inthandler to make it tolerant to whatever
pcspkr does. But this is quite an evil hack, and an unnecessary code
pollution which I'd like to avoid.
Adding a dummy input driver, as per Bodo Eggert, doesn't look very good
to me either. If nothing else then at least because it won't be called
pcspkr, so the confusion is still unavoidable.

Adding a few ALSA guys to CC, who used to help with the snd-pcsp in
the past.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Hi.

Dmitry Torokhov wrote:
> etc. All these alternative bells would not disrupt operation of your
> snd_pcsp module but it still would disable the bell because it does
> not know better.
OK, I now used INPUT_DEVICE_ID_MATCH_BUS, and, with something
like the attached patch, it seems to work. So essentially my
driver has enough of the knowledge about the device in question,
and this seems to be possible exactly only with the input subsystem.
(which makes me confident again that using the input subsystem
was exactly the right choice :)
What do you think about that approach?


[-- Attachment #2: input_en.diff --]
[-- Type: text/x-patch, Size: 1637 bytes --]

--- a/include/linux/input.h	2006-04-05 17:10:01.000000000 +0400
+++ b/include/linux/input.h	2006-04-05 17:36:49.000000000 +0400
@@ -862,7 +862,7 @@
 
 	struct pt_regs *regs;
 	int state;
-
+	int enabled;
 	int sync;
 
 	int abs[ABS_MAX + 1];
@@ -1019,6 +1019,8 @@
 int input_open_device(struct input_handle *);
 void input_close_device(struct input_handle *);
 
+void input_enable_device(struct input_handle *handle, int enab);
+
 int input_accept_process(struct input_handle *handle, struct file *file);
 int input_flush_device(struct input_handle* handle, struct file* file);
 
--- a/drivers/input/input.c	2006-01-12 11:23:09.000000000 +0300
+++ b/drivers/input/input.c	2006-04-05 17:51:27.000000000 +0400
@@ -36,6 +36,7 @@
 EXPORT_SYMBOL(input_release_device);
 EXPORT_SYMBOL(input_open_device);
 EXPORT_SYMBOL(input_close_device);
+EXPORT_SYMBOL(input_enable_device);
 EXPORT_SYMBOL(input_accept_process);
 EXPORT_SYMBOL(input_flush_device);
 EXPORT_SYMBOL(input_event);
@@ -52,7 +53,7 @@
 {
 	struct input_handle *handle;
 
-	if (type > EV_MAX || !test_bit(type, dev->evbit))
+	if (type > EV_MAX || !test_bit(type, dev->evbit) || !dev->enabled)
 		return;
 
 	add_input_randomness(type, code, value);
@@ -265,6 +266,11 @@
 	up(&dev->sem);
 }
 
+void input_enable_device(struct input_handle *handle, int enab)
+{
+	handle->dev->enabled = enab;
+}
+
 static void input_link_handle(struct input_handle *handle)
 {
 	list_add_tail(&handle->d_node, &handle->dev->h_list);
@@ -712,6 +718,7 @@
 		class_device_initialize(&dev->cdev);
 		INIT_LIST_HEAD(&dev->h_list);
 		INIT_LIST_HEAD(&dev->node);
+		dev->enabled = 1;
 	}
 
 	return dev;

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Joseph Fannin]

On Sun, Mar 26, 2006 at 01:52:50PM +0400, Stas Sergeev wrote:
> Bodo Eggert wrote:
>>>The problem is that the snd-pcsp doesn't replace pcspkr.

>>If that's the problem, create a minimal input driver that will signal the
>>snd-pcsp to beep, and change the original pcspkr to include
>>"(Non-ALSA)".

> Yes, making snd-pcsp to produce the console beeps and
> making it mutually exclusive with pcspkr is possible.
> But I think it is undesireable. People that don't like
> the console beeps (myself included) simply do not load
> the pcspkr module right now. If snd-pcsp is to produce
> the beeps, then not loading pcspkr will not get the desired
> effect any more, and the only possibility would be to,
> probably, add the separate mixer control for the beeps.
> I find this counter-intuitive: some people will be able to
> disable the beeps by simply not loading pcspkr, while for
> others this will suddenly magically stop working. This may
> lead to a few unnecessary bug reports and confusions.

    My laptop already has such a mixer control (and it works too,
though it does depend on pcspkr being loaded).  Have there been bug
reports about PC speakers that don't work because the PC speaker mixer
control was not unmuted?  Well, probably, but it's not a new
situation.

    It doesn't seem unreasonable to me to expect users to configure
their PC speaker beep preference through the ALSA mixer when
configuring the PC speaker to be an audio device.

    I would think the ideal situation would be to make every ALSA
device capable of acting as the console bell (defaulting to muted,
like every other ALSA mixer control).  Then only pcspkr would be the
odd case (though maybe a common one).

    I dunno if there's a reasonably easy way to do that (without
changing every ALSA driver) though.
--
Joseph Fannin
jfannin@gmail.com

"That's all I have to say about that." -- Forrest Gump.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Bodo Eggert]

On Tue, 28 Mar 2006, Joseph Fannin wrote:

>     I would think the ideal situation would be to make every ALSA
> device capable of acting as the console bell (defaulting to muted,
> like every other ALSA mixer control).  Then only pcspkr would be the
> odd case (though maybe a common one).
> 
>     I dunno if there's a reasonably easy way to do that (without
> changing every ALSA driver) though.

I think that should be done using a userspace input device if possible.
-- 
A man inserted an advertisement in the classified: Wife Wanted."
The next day he received a hundred letters. They all said the
same thing: "You can have mine."

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Vojtech Pavlik]

On Tue, Mar 28, 2006 at 08:43:35PM +0200, Bodo Eggert wrote:
> On Tue, 28 Mar 2006, Joseph Fannin wrote:
> 
> >     I would think the ideal situation would be to make every ALSA
> > device capable of acting as the console bell (defaulting to muted,
> > like every other ALSA mixer control).  Then only pcspkr would be the
> > odd case (though maybe a common one).
> > 
> >     I dunno if there's a reasonably easy way to do that (without
> > changing every ALSA driver) though.
> 
> I think that should be done using a userspace input device if possible.
 
It certainly is. That way configuring the exact sound it makes would
also possible. The latency might be a problem, though.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Edgar Toernig]

Vojtech Pavlik wrote:
>
> On Tue, Mar 28, 2006 at 08:43:35PM +0200, Bodo Eggert wrote:
> > On Tue, 28 Mar 2006, Joseph Fannin wrote:
> > 
> > >     I would think the ideal situation would be to make every ALSA
> > > device capable of acting as the console bell (defaulting to muted,
> > > like every other ALSA mixer control).  Then only pcspkr would be the
> > > odd case (though maybe a common one).
> > > 
> > >     I dunno if there's a reasonably easy way to do that (without
> > > changing every ALSA driver) though.
> > 
> > I think that should be done using a userspace input device if possible.
>  
> It certainly is. That way configuring the exact sound it makes would
> also possible. The latency might be a problem, though.

Latency is no problem.  I'm using a userspace daemon to emulate
the console beeper for about 6 months now and it work's very well.

The daemon listens on /dev/input/eventX and when receiving a
SND_TONE it opens /dev/dspY (a cheap USB-speaker), produces its
bing and closes the audio dev after some seconds with no SND_TONE.

Latency isn't noticable and memory footprint is small.

Sure, if ALSA could emit console beeps on any audio device even if
it is in use I would definitely use it and trash the USB-speaker.
But the userspace daemon is OK...

Ciao, ET.

PS:
<rant>
It would have been even better if Shuttle had connected the beeper
output of the IT87 to the beeper input of the ALC650 in the first
place.  But no, this thing is totally silent - no piezo beeper, no
routing to the sound codec, no POST-beeps, nothing.

Why are manufacturers doing such silly things?
</rant>

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Vojtech Pavlik]

On Fri, Mar 31, 2006 at 01:07:34AM +0200, Edgar Toernig wrote:
> Vojtech Pavlik wrote:
> >
> > On Tue, Mar 28, 2006 at 08:43:35PM +0200, Bodo Eggert wrote:
> > > On Tue, 28 Mar 2006, Joseph Fannin wrote:
> > > 
> > > >     I would think the ideal situation would be to make every ALSA
> > > > device capable of acting as the console bell (defaulting to muted,
> > > > like every other ALSA mixer control).  Then only pcspkr would be the
> > > > odd case (though maybe a common one).
> > > > 
> > > >     I dunno if there's a reasonably easy way to do that (without
> > > > changing every ALSA driver) though.
> > > 
> > > I think that should be done using a userspace input device if possible.
> >  
> > It certainly is. That way configuring the exact sound it makes would
> > also possible. The latency might be a problem, though.
> 
> Latency is no problem.  I'm using a userspace daemon to emulate
> the console beeper for about 6 months now and it work's very well.
> 
> The daemon listens on /dev/input/eventX and when receiving a

It needs to use /dev/input/uinput, not eventX. SND_TONE events are not
sent to the event devices.

> SND_TONE it opens /dev/dspY (a cheap USB-speaker), produces its
> bing and closes the audio dev after some seconds with no SND_TONE.
> 
> Latency isn't noticable and memory footprint is small.

It needs to have the sample ready in memory and not swapped out. Then
the latency will be OK, but if it needs to read it in from the disk, it
may be very noticeable.

> Sure, if ALSA could emit console beeps on any audio device even if
> it is in use I would definitely use it and trash the USB-speaker.
> But the userspace daemon is OK...

> PS:
> <rant>
> It would have been even better if Shuttle had connected the beeper
> output of the IT87 to the beeper input of the ALC650 in the first
> place.  But no, this thing is totally silent - no piezo beeper, no
> routing to the sound codec, no POST-beeps, nothing.

Pretty common nowadays.

> Why are manufacturers doing such silly things?
> </rant>


-- 
Vojtech Pavlik
Director SuSE Labs

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Edgar Toernig]

Vojtech Pavlik wrote:
>
> On Fri, Mar 31, 2006 at 01:07:34AM +0200, Edgar Toernig wrote:
> >
> > Latency is no problem.  I'm using a userspace daemon to emulate
> > the console beeper for about 6 months now and it work's very well.
> > 
> > The daemon listens on /dev/input/eventX and when receiving a
> 
> It needs to use /dev/input/uinput, not eventX. SND_TONE events are not
> sent to the event devices.

Well, I get them - stock 2.6.16.


> > Latency isn't noticable and memory footprint is small.
> 
> It needs to have the sample ready in memory and not swapped out. Then
> the latency will be OK, but if it needs to read it in from the disk, it
> may be very noticeable.

Yeah, if one ever cares one could mlock the samples, or (as I do) run
without swap.  Fixing the 'air' latency of 3ms/m is harder though *g*

Ciao, ET.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Vojtech Pavlik]

On Fri, Mar 31, 2006 at 11:06:35PM +0200, Edgar Toernig wrote:
> Vojtech Pavlik wrote:
> >
> > On Fri, Mar 31, 2006 at 01:07:34AM +0200, Edgar Toernig wrote:
> > >
> > > Latency is no problem.  I'm using a userspace daemon to emulate
> > > the console beeper for about 6 months now and it work's very well.
> > > 
> > > The daemon listens on /dev/input/eventX and when receiving a
> > 
> > It needs to use /dev/input/uinput, not eventX. SND_TONE events are not
> > sent to the event devices.
> 
> Well, I get them - stock 2.6.16.

Oh, yes, you're right. But still, this will only work if a speaker
device is present, so uinput is the right way to do it.

> > > Latency isn't noticable and memory footprint is small.
> > 
> > It needs to have the sample ready in memory and not swapped out. Then
> > the latency will be OK, but if it needs to read it in from the disk, it
> > may be very noticeable.
> 
> Yeah, if one ever cares one could mlock the samples, or (as I do) run
> without swap.  Fixing the 'air' latency of 3ms/m is harder though *g*

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hi.

[ adding LKML to CC and removing akpm as this went into a
discussion phase apparently ]

Dmitry Torokhov wrote:
> Yes, I remember. And after re-reading all of it now I still see that
> he wasn't really happy with the solution.
Yes, neither did I, but there always should be some
compromiss if the better solution is not found. :)

>> Well, the main reason behind that change, is that there is a PC-Speaker
>> PCM driver/emulator, snd-pcsp, pending in an ALSA CVS. I can't get it
>> included in kernel before there is a way to disable the pcspkr driver.
> Why can't you? We have ALSA and OSS together in the kernel just fine.
But the pcspkr driver is not an OSS, it is an "input" driver.

> If you are concerned about both modules baing active at the same time
> do not let user compile pcspkr if snd_pcsp is selected for now.
The problem is that the snd-pcsp doesn't replace pcspkr. And if I do
what you say, whoever opted to use snd-pcsp, will no longer be able
to hear the console beeps, and that I find a disadvantage.
I myself do not like the console beeps, but some people will really
complain. So I'd like to find another solution if possible, and the
input solution looked quite what I needed.

>> only to disable it. OTOH, if someone loads pcspkr while snd-pcsp is
>> running, the input subsystem notifies snd-pcsp so that it can immediately
>> disable pcspkr, to not let it to harm even in that case.
> Does it? How does it do it? There is no "new driver" event in the
> input subsystem...
But I register an input handler, and whenever the pcspkr driver is
loaded, my "connect" handler is invoked, and from there I send an
SND_SILENT.

> No, I don't want SND_SPKR_STARTED either.
OK, how about something under a SYN_CONFIG then?

> What you need is a way to
> disable a certain driver somehow and I think it is a task that belongs
> to driver core, not input or any other individual subsystem.
But what if I just want to grab SND_BELL so that it is delivered
exclusively to my driver? Intuitively, I'd use the input subsystem
for that, but unfortunately it simply doesn't have that grabbing
capability (I asked Vojtech to be sure - he confirmed that there
is none). Be there such a capability, that would be excellent, no
hacks will be needed. But if I modify the pcspkr driver to disable
it directly via some function call, then snd-pcsp will always load
pcspkr, which is highly undesireable. I am not sure what did you
mean about the driver core though.

> Because
> next time you want to disable for example a framebuffer driver because
> you have written better one and you are back to square 1.
The difference is that the snd-pcsp and pcspkr drivers are doing the
completely different tasks. snd-pcsp doesn't absolete pcspkr - being
an ALSA driver it only plays sound, but doesn't do the console beeps,
thats the problem. Somehow I have to make sure they both can peacefully
co-exist. Making them mutually exclusive is bad, and making them
dependant (by calling into each other directly) is also rather bad.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Dmitry Torokhov]

On 3/23/06, Stas Sergeev <stsp@aknet.ru> wrote:
>
> > Because
> > next time you want to disable for example a framebuffer driver because
> > you have written better one and you are back to square 1.
> The difference is that the snd-pcsp and pcspkr drivers are doing the
> completely different tasks. snd-pcsp doesn't absolete pcspkr - being
> an ALSA driver it only plays sound, but doesn't do the console beeps,
> thats the problem. Somehow I have to make sure they both can peacefully
> co-exist. Making them mutually exclusive is bad, and making them
> dependant (by calling into each other directly) is also rather bad.
>

OK, you need to tell me again what snd_pcsp and what exactly it
functions are, because I am confised at the moment. If it is just for
playing sounds/music through PC speaker then I don't understand why
you want to disable pcspkr driver - if people don't like terminal
beeps they can disable it.

--
Dmitry

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hi.

Dmitry Torokhov wrote:
> OK, you need to tell me again what snd_pcsp and what exactly it
> functions are, because I am confised at the moment.
It is a PCM emulation driver - like any other ALSA PCM driver
it can play a digital sound, emulating the 5bit PCM stream
on a 1bit PC-Speaker device. (actually it pretends to be a
16bit stereo device, but what it produces is a 5bit mono sound)

> If it is just for
> playing sounds/music through PC speaker then I don't understand why
> you want to disable pcspkr driver - if people don't like terminal
> beeps they can disable it.
The problem is that when the snd_pcsp is playing, the terminal beeps
will "destroy" it, as they reprogram the PIT channel 2. So I need a
way to disable pcspkr while the PCM is playing, but re-enable it as
soon as the PCM output stopped.
This only means people won't hear the terminal beeps while they "listen
to the music", but this is not as big problem as disabling these beeps
completely when snd_pcsp is selected in the config.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Dmitry Torokhov]

On 3/23/06, Stas Sergeev <stsp@aknet.ru> wrote:
> Hi.
>
> Dmitry Torokhov wrote:
> > OK, you need to tell me again what snd_pcsp and what exactly it
> > functions are, because I am confised at the moment.
> It is a PCM emulation driver - like any other ALSA PCM driver
> it can play a digital sound, emulating the 5bit PCM stream
> on a 1bit PC-Speaker device. (actually it pretends to be a
> 16bit stereo device, but what it produces is a 5bit mono sound)
>
> > If it is just for
> > playing sounds/music through PC speaker then I don't understand why
> > you want to disable pcspkr driver - if people don't like terminal
> > beeps they can disable it.
> The problem is that when the snd_pcsp is playing, the terminal beeps
> will "destroy" it, as they reprogram the PIT channel 2. So I need a
> way to disable pcspkr while the PCM is playing, but re-enable it as
> soon as the PCM output stopped.

So what you actually need is a mediator module controlling concurrent
access to the speaker hardware from both pcspkr and snd_pcsp and
making sure that one does not disrupt the other. This is completely
outside of the scope of the input subsystem tough.

> This only means people won't hear the terminal beeps while they "listen
> to the music", but this is not as big problem as disabling these beeps
> completely when snd_pcsp is selected in the config.

You are right, I misunderstood the purpose of snd_pcsp. Still the best
solution would be to allow beeps to come through if user keeps them
enabled.

--
Dmitry

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hi.

Dmitry Torokhov wrote:
> So what you actually need is a mediator module controlling concurrent
> access to the speaker hardware from both pcspkr and snd_pcsp and
> making sure that one does not disrupt the other. This is completely
> outside of the scope of the input subsystem tough.
Strictly speaking - yes. But, to make my life easier, I am trying
to approach it from the other sides as well:
Why not to have a SYN_CONFIG option to disable the terminal beeps
with *any* speaker driver (sparkspkr, m68kspkr etc)?
Or, why not to have the grabbing capability in the input layer, so
that the driver can request an exclusive handling of some events?
Both the above options look usefull in general, and I can get the
use of either one. Do you think both of the above options are bad
in general? (you may disagree with the way I am going to use them,
but that doesn't make them bad in general, I think)

> You are right, I misunderstood the purpose of snd_pcsp. Still the best
> solution would be to allow beeps to come through if user keeps them
> enabled.
But they really kill the snd_pcsp if they occur. They reprogram the
PIT channel 2 to a different mode, and the sound doesn't resume
after the beep, there is just some crackling remains. And it is
not even under the user's control - Mozilla mailer beeps me when
receives the mail for example. So not disabling pcspkr will make
the snd_pcsp very unreliable.

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Dmitry Torokhov]

On 3/23/06, Stas Sergeev <stsp@aknet.ru> wrote:
> Hi.
>
> Dmitry Torokhov wrote:
> > So what you actually need is a mediator module controlling concurrent
> > access to the speaker hardware from both pcspkr and snd_pcsp and
> > making sure that one does not disrupt the other. This is completely
> > outside of the scope of the input subsystem tough.
> Strictly speaking - yes. But, to make my life easier, I am trying
> to approach it from the other sides as well:
> Why not to have a SYN_CONFIG option to disable the terminal beeps
> with *any* speaker driver (sparkspkr, m68kspkr etc)?

Because what happens when ther is a third party involved. As you know
the good design account for either "zero", "one" or "many"
clients/accessors. Code in anticipation of having only 2 possible
users is not a good practice.

> Or, why not to have the grabbing capability in the input layer, so
> that the driver can request an exclusive handling of some events?

That can be explored, although does not answer how you do about
allowing concurrent access to the hardware.

> Both the above options look usefull in general, and I can get the
> use of either one. Do you think both of the above options are bad
> in general? (you may disagree with the way I am going to use them,
> but that doesn't make them bad in general, I think)
>
> > You are right, I misunderstood the purpose of snd_pcsp. Still the best
> > solution would be to allow beeps to come through if user keeps them
> > enabled.
> But they really kill the snd_pcsp if they occur. They reprogram the
> PIT channel 2 to a different mode, and the sound doesn't resume
> after the beep, there is just some crackling remains. And it is
> not even under the user's control - Mozilla mailer beeps me when
> receives the mail for example.

Doesn't it go through XBell (xkbbell to disable)?

> So not disabling pcspkr will make
> the snd_pcsp very unreliable.
>

I understand that the beeps kill music currently; they should not if
you have lower level module controlling access.

--
Dmitry

Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Dmitry Torokhov wrote:
>> Or, why not to have the grabbing capability in the input layer, so
>> that the driver can request an exclusive handling of some events?
> That can be explored, although does not answer how you do about
> allowing concurrent access to the hardware.
I could simply grab SND_BELL so that the pcspkr won't even receive it.

> I understand that the beeps kill music currently; they should not if
> you have lower level module controlling access.
OK, that's a driver core stuff then, you are right.
I'll see what can be done about the legacy/ISA devices there,
but from the first glance it doesn't look promising...