|
From: Henrique de M. H. <hm...@hm...> - 2007-02-25 01:20:37
|
Hello, I am the current maintainer of the ibm-acpi driver for the Linux kernel. Those of you that own a ThinkPad notebook probably know what I am talking about. A ThinkPad notebook has a hardware mixer for volume control (two functions: volume and mute). The user can interact with this volume control using three buttons (up/down/mute), and it is completely implemented in firmware. ibm-acpi currently exports those controls through a procfs interface, but I am trying to get rid of it, and instead of just porting the interface to sysfs attributes, I tried to write a proof-of-concept alsa mixer -- if it is a mixer, it should be exported as one, not as some driver-specific sysfs attributes, IMHO :-) It worked almost perfectly, and it was easy to write. Many thanks to Takashi Iwai for his excellent docs at http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html. 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. 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? -- "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 |
