On Wed, 2007-05-16 at 10:10 -0300, Henrique de Moraes Holschuh wrote: > 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. So you don't want to do any dmi-based matching in thinkpad_acpi at all? When the dmi kernel class is upstream this could be pretty easy, although I don't mind doing it in userspace with a keymap. > > 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. Yes, you're completely correct. > And it doesn't > mean we can't monitor the keys too, since there are other keys that need > monitoring anyway. Sure, web keys and that sort of thing. > 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. Sure. > Well, worse come to worst, we can send them over ACPI. Ick :-) > > > 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. Okay, I'll spend a few hours on it tonight, and see what I can come up with. > This doesn't mean I promise > to take the patch as is, of course, but I think that functionality is a good > idea. Of course! > > 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. I'm glad we agree. I'll get hacking now. Many thanks for your help with this. Richard. ------------------------------------------------------------------------- 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
