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.
On 3/23/06, Stas Sergeev <[email protected]> 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
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.
On 3/23/06, Stas Sergeev <[email protected]> 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
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.
On 3/23/06, Stas Sergeev <[email protected]> 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
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...