Stas Sergeev <[email protected]> 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.
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.
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...
>>> 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
--
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
On 3/26/06, Stas Sergeev <[email protected]> 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
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.
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
[email protected]
"That's all I have to say about that." -- Forrest Gump.
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."
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
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>
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
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.