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

[Dmitry Torokhov]

On 3/23/06, Stas Sergeev <stsp@xxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/