|
From: Henrique de M. H. <hm...@hm...> - 2007-03-07 23:03:02
|
On Wed, 07 Mar 2007, Takashi Iwai wrote: > Well, it's a question whether this should be an add-on module or a > built-in to the sound driver. From the usability viewpoint, the > latter is much easier. Then we have no module loading order problem > and need no API extension. Of course, the drawback is that the > unnecessary growth of the code / binary size for non-thinkpad users. Which is quite a serious drawback. I am not at all opposed to writing a mixer piggy-back, but IMHO if we are going to do it that way, it would be best to create an API that allows an alsa module to extend the functionality of another module, *and* provide the proper callbacks to have it work in full hotplug mode (i.e. it will do the right thing no matter in which way the modules are loaded, and also if the device is hotplugged or hotunplugged). > > > I suppose it does mean you can use alsamixer to manipulate the sound, > > > but from the user's point of view, if it's not visible when they right > > > clock on the mixer applet (because it's not associated with the > > > laptop's primary sound card), is it really that useful? > > > > If they got a mixer applet worth something, it will list two cards, or allow > > them to have two instances, one for each card. > > I guess it's rather confusing. Both controls the very same device for > the very same role in the end, so it'd be better to be merged in some > level, IMO. Very well. Do you want me to start a "requirements" document for the API, so that we can start walking down that road? On the ibm-acpi side, I can just merge in the mixer as a separate card for now, with the proper notices that it is not a stable interface and that it will go away in the future. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh |
