At Fri, 02 May 2008 20:57:00 +0400,
Stas Sergeev wrote:
[Oops, overseen this follow up]
One problem is that we cannot load two drivers to a single device
right now. Even if you have input pcspkr and snd-pcsp modules, you
have to blacklist one of two modules so that udev loads the one
properly. Because of this, snd-pcsp will be unlikely activated for
most systems as default.
For avoiding this, you'll have a few choices:
a) implement pcspkr-core driver, and make input-pcspkr and snd-pcsp on
that core module
b) make snd-pcsp copmletely rely on input pcspkr, implement as an
add-on by adding hook to each driver callback and event handler of
pcspkr
c) implement snd-pcsp as another individual platform driver and adds a
hook to pcskr event handler of pcspkr
The case (a) would make things more complicated and give less
solution.
In the case (b), the modification of pcspkr.c would be big, and
would be ugly.
The case (c) was my proposal. But in this case, the driver will
become likely self consistent; it allocates its own device at init.
In anyway, there is no sexy way to auto-load snd-pcsp (partly because
it's the purpose -- avoid loading the sound subsystem unless really
necessary). That's why I called it hackish.
Takashi
--
