Could we handle this by setting a nomixerreset=1 option in modules.conf
or as the module default that would effect module reloads. Then on boot
up explicitly modprobe with a mixerlevel=0 and then set the levels via
aumix etc?
This way the existing hardware can keep the levels if it knows how. As
mentioned there would also have to be a setlevels user script called
after suspend/resume.
Barring this, we could create a persistantdata module that we can
modprobe and then discover with Keith's inter_module_xxx and read/write
opaque data to/from. Then if the user does not want to use it they can
just "alias persistantdata off" it and poof.
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > The best solution to the sound driver issue, IMHO, is still entirely
> > userspace--- just no-one has written it yet. What we should do: 1.
> > Before auto-unload of the driver, run a small utility which will read
> > mixer settings
> > and save them somewhere 2. When auto-loading the driver, use driver
> > arguments which are initialized from the
> > settings saved above
>
> That could work, although it may be better to make it more generic and
> capable of handling any form of data.
>
> Any form of persistent storage would do - and if it can be handled entirely
> in userspace, all the better. I merely pointed out that Keith's
> inter_module_xxx could provide this quite cleanly. Others disputed that it
> was required at all.
>
> --
> dwmw2
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
