At Mon, 26 Feb 2007 13:28:19 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 26 Feb 2007, Takashi Iwai wrote: > > > The only issue was in userspace, apparently alsamixer ignores VOLATILE > > > controls and doesn't poll them for updates. I wonder how widespread such > > > misbehaviour is? I may have to write an in-driver polling thread so that I > > > can send notifications, if it is too widespread. > > > > That's exactly the role of VOLATILE flag. It's for controls with > > frequently changing elements (e.g. VU-meters) and thus not suitable > > for poll/select by a mixer app. I think the case of volume buttons is > > OK to use normal controls without VOLATILE flag. > > Well, since these controls change without notice (user might press a volme > button in the keyboard, and the firmware will change the volume by itself), > I will have to poll them myself and send notifications. Hm, yes, if there is no irq or such, the polling is the only way... > > > Anyway, the driver is *not* a stand-alone module, but rather just a small > > > part of ibm-acpi. I suppose I could break it into two modules so that the > > > alsa mixer has its own module, but either it would *have* to depend on > > > ibm-acpi, or it would have to duplicate a lot of thinkpad specific stuff. > > > > > > How do you guys feel about an in-tree module that has alsa stuff in it, but > > > is not part of the alsa tree? Would that be a problem? > > > > I'm basically for including it in ALSA driver (suppose intel8x0?) as > > long as it's directly related with the sound. If you have a working > > patch, I'm willing to review and discuss more. > > It is not directly related to the sound card *at* *all*. It is done by the > thinkpad embedded controller firmware. > > So, it really is a "different card", and doesn't belong in any of the many > sound card drivers that work on the various thinkpad models. Since it is > only one extra mixer control, if the API allows it, we *could* piggy back it > on the mixer for the real sound card, but that looks like extra complexity > and layering violations for no good reason to me. Hm, I think the problem is how to export the sound card object to the outside. Currently the created instance is closed in the ALSA tree, and there is no direct way to get the pointer from another driver. That's why I thought of including the code in the ALSA tree. But, we can add an export to enable the hook in each card driver code. > If I have it as a separate snd-thinkpadmixer module or somesuch, that module > will need some code from the main ibm-acpi module to work. It needs the > ACPI bus, and also thinpad-specific knowledge... sounds messy to have it on > a different tree, thus the question about how complicated would it be to > have it in the ibm-acpi driver instead of submitting it for the alsa tree. I think it's no big problem to leave it in another tree since the control API is fairly stable right now. Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
