[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: discover or alsa? Solution proposal.



On Wed, 2004-10-13 at 10:30 +0200, Thomas Hood wrote:
> Lots of users are reporting that ALSA sound doesn't "just" work when
> they install it.  The cause of the problem is the fact that discover
> loads OSS modules even when ALSA modules are available.  This bug cannot
> be worked around consistently with policy because discover offers no
> mechanism for blacklisting modules other than editing a conffile.  The
> bug report against discover1 (#220616) has been tagged "wontfix" so I am
> not expecting the discover maintainers to solve the problem.
> 
> Given these facts, what should the ALSA packaging team do?  It seems
> that the alsa packages should Conflict with discover and discover1.

I have a solution.

Hotplug has many many great features. One such feature
== /etc/hotplug/blacklist.d

If ALSA is the preferred sound solution, then the alsa-base maintainer
should present a list in hotplug with all of the traditional "oss"
drivers names in a file called alsa-base. hotplug will indeed not load
these files.

Now, I propose, that since Discover v2 DOES indeed use modprobe to load
its modules... alsa-base should have a similar list in something
like /etc/discover/blacklist.d called alsa-base with the skip="" done
for all of the OSS modules.

Now, this COULD be all addresses, in one way. Force discover and hotplug
to honor a file in /etc/modprobe.d/alsa-base, which is currently there
already but only has a few entries. Or just make sure they call modprobe
vs anything else.

If the entries where there for every OSS module, not just the ones there
now (three redirections only) then it could be done with more ease. Sure
I know it'd make the job of Jordi Mallach, Steve Kowalik, David B.
Harris and Thomas Hood more painful...

But, I'd even be willing to do the grunt work for the file if need be.
It would seem to be a file with a bunch of CNP then edit. Of course, I
am no programmer but understand programming from an Network and Systems
Hardware Analyst POV.

It is an idea, but will anyone think it a good one?
-- 
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster:  Linux

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: