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

From: Stas Sergeev
Date: Thu Mar 23 2006 - 13:00:15 EST


[ 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

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.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at