At Wed, 30 Apr 2008 21:45:59 +0400,
Stas Sergeev wrote:
quoted text
> 
> Hello.
> 
> Takashi Iwai wrote:
> >> I was trying this in the past.
> >> This never worked out very well.
> > Why?
> Mainly because I was not able to
> come up with the good hooks for the
> pcspkr driver, and those I tried,
> were not applied.
> There was a lengthy thread about that.
> Now I can't find its beginning and its
> end, but some is here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html
> I also think you were CCed, but maybe
> not.
> 
> >> I disliked the dependancies.
> >> Either snd-pcsp was loading pcspkr,
> >> or there had to be the global variable
> >> to prevent the concurrent access, and
> >> that hurts modularity.
> > But you anyway enable the input pcspkr feature in your snd-pcsp code.
> > So, basically you depend on (or build on) it.
> If they are separate, then "rmmod pcspkr"
> should disable the beeps.

But, they are *not* seperate right now.  snd-pcsp contains pcspkr
functionality.

quoted text
> I don't want
> to fuzzy that logic up to something like
> - Check if snd-pcsp is loaded
> - Use alsamixer to disable beeps, if
> it is.
> - Use rmmod pcspkr if it is not.
> I think there should be always a single
> way for the user to disable the beeps.
> Now he can choose it by chosing the driver.

And this won't work in most cases.  People don't want to replace the
existing pcspkr driver with snd-pcsp.  They don't want to load the
sound subsystem on their systems just because of beep.

quoted text
> >>> What we'd need is a hook on
> >>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
> >>> is running.
> >> How?
> > What you need is a way to check whether input pcspkr can be usable or
> > not.  You can add a function pointer, for example.
> Could you please clarify?
> - Should snd-pcsp then forcibly select
> pcspkr.c to compile?
> - What exactly function pointer, and
> where to add?

If you compare pcspkr.c and pcsp_input.c, it's found that the only
essential difference is the additional check at the head of the event
handler:

	if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr)
		return 0;

If this can be added dynamically to input pcspkr.c, no big point to
have duped codes.

quoted text
> >> And also, with snd-pcsp you have a
> >> mixer control to disable the beeps,
> >> which I find sometimes even more
> >> usefull than the pcm sound itself. :)
> > Yes, that seems useful.
> Yes, but problematic when they are separate.
> I was trying to add an input event to shut
> up pcspkr.c, but that was rejected. Everything
> else will introduce the dependancy. The
> dependancy will block rmmod, obfuscating the
> logic of disabling the beeps.
> Just for the record, what problems do you
> see with the current solution, where only
> one driver drives the device? That looks
> rather logical to me. And I also can remember
> the complains about pcspkr driver being in
> an input drivers section. Some people had
> problems finding it there and were asking
> to move it to sound menu.

Distros usually make input-pcspkr as built-in, not as module.
So, snd-pcsp is practically unusable on standard kernels of major
distros as is, unfortunately...


Takashi
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/