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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
