On Wed, 2007-05-16 at 00:12 -0300, Henrique de Moraes Holschuh wrote: > On Tue, 15 May 2007, Richard Hughes wrote: > > Hi, sorry for the direct mail, please feel free to CC this message to > > the revelant lists. > > That would be ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxxx CC added. Cheers. > > I've been asked to add tpd-like interfaces to userspace for an x60, so > > that the volume up, down and mute buttons are working in userspace. To > > Why? Did Lenovo break those keys in the X60? They usually manipulate the > machine's hardware mixer in firmware, and trying to process them in > userspace just ends up causing problems... > > > do this I need to use nvram as this is not exported in ACPI. > > Correct. > > > I really have two options, add the code to the thinkpad_acpi.c kernel > > driver and export the nvram functions and then push the buttons > > through INPUT so that we can deal with them in the normal way or to > > add a HAL addon to do the polling in userspace. > > 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. > But it needs to be optional, and before I accept any such things, I need to > know why are them necessary. No other recent thinkpad I know needs > something messing with the volume keys, unless you are using the audio > interface in the dock/port-replicator, which for some foolish reason is > derived *before* the internal hardware mixer. 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. > > The HAL addon is quite trivial (~30 LOC) but means that input events > > are going via uinput which is oviously non-ideal. I can add code to > > thinkpad_acpi to do this fairly cleanly (with your help) if this is > > acceptable to you guys. > > 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. 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. Thanks for your help so far, Richard Hughes ------------------------------------------------------------------------- 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
