On Wed, 16 May 2007, Richard Hughes wrote: > > thinkpad-acpi has a feature scheduled to export control of the mixer these > > keys control as an alsa mixer device, so I wouldn't mind much adding input > > processing too. We will need to get there for properly handling the fn+x > > keys anyway. > > Yes, I was also looking at them. Some already get squirted through ACPI > (power button type) but most are like battery (FnF3): > > ibm/hotkey HKEY 00000080 00001003 > > and only enabled when I do "echo enable,0xffff >/proc/acpi/ibm/hotkey". > Converting these to INPUT is probably the best plan first. The plan is to get all hotkeys sent to userspace through INPUT, using a "hotkey fX" or something equally generic. I can't translate from fn+f3 to fn+battery, as that's model specific knowledge. > Sure, I totally understand. The primary reason I want the status of > these (hw) buttons is to integrate them with gnome OSD for stuff like > gnome-session and that sort of thing, rather than rely on XOSD like > before. There's also some other buttons I want to be able to map to > arbitrary stuff, like the 'thinkpad' button. The main problem is the > reporting is that some has to be passive "volume has been turned up" > rather than active "please turn volume up" - but I still think we can do > this with INPUT. Yes, we can. But maybe you could just monitor the forthcoming thinkpad ALSA mixer for the hardware state, instead? You would be monitoring the *effects* and not the cause, which is actually a good thing. And it doesn't mean we can't monitor the keys too, since there are other keys that need monitoring anyway. But it is not a good idea to issue volume up/down/mute INPUT events for those keys (unless that too is optional), these events are typically active ones from multimedia keyboards. It will cause trouble. We will need other events. Well, worse come to worst, we can send them over ACPI. > > It has to be optional, and it needs to support all tpb-like keys. Other > > than that, yes, it might be acceptable. > > Sure. Has anybody else looked at INPUT on thinkpad_acpi, or would you > like me to just in and start coding? I think converting the hotkeys to > INPUT would be my first task, and then working on NVRAM hardware keys > when the first stuff is merged. If you send me code, it will speed up adoption. This doesn't mean I promise to take the patch as is, of course, but I think that functionality is a good idea. > I really don't want to add yet another daemon that polls stuff and mucks > about with acpi keys when we can do this properly (IMO) in the kernel. I hate the idea of any extra polling. We need proper interfaces with unix fd semanthics that you can poll() and select() on in sysfs. -- "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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
