On Mon, 2007-05-21 at 13:37 +0100, Richard Hughes wrote: > On Mon, 2007-05-21 at 09:26 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 21 May 2007, Richard Hughes wrote: > > > > You get full credits, of course, and I will wait an ACK from you before I > > > > push it anywhere. It was your idea, and your patch probably is just fine as > > > > far as "it works" goes, so you get to comment and offer suggestions before I > > > > merge it. > > > > > > One comment I was about to make, are the INPUT events emitted even > > > without a "echo enable,0xffff >/proc/acpi/ibm/hotkey"? > > > > No, they are not. > > Ick. Ick indeed. It should really be automatic (ie. no need to poke anywhere to get the events back to user-space). > > I am working on letting one change which input events are sent for each > > hotkey, though. I will also try to get the KEY_FN_* missing macros in > > input.h, but if that fails, well, at least it will be configurable. > > Sure, I think only KEY_FN_HOME and KEY_FN_END are needed for my X60. > > Alternatively, we could match against the dmi data (from the dmi class) > and then do the conversion of FnF2 to KEY_LOCK in the thinkpad_acpi > driver itself. For the additional keys, I mentioned to Richard using "KEY_F13" and above (really depending on the number of functions keys on those keyboards), for keys which can't be easily mapped to existing keycodes. > > It is a pity the sonypi guys got some non-generic keys in there instead of > > asking for a set of 16 "KEY_MODELSPECIFC_1..16" or somesuch which we could > > use for these things. All FN keys should be something like that, in fact... > > or we should just work on expanding the !@#$ keycode space right away, > > trying to limit the usefulness of these things is a bad idea, anyway... > > Heh, yes, frustrating. I know about that, as I tried to get Stelian to accept a patch to allow DMI-matching on those laptops, so all the keys which have symbols on them would have the appropriate keycodes bound to them, rather than keycodes that don't mean anything to user-space. > > > >From a end user perspective, this stuff should probably just work. > > > > I am still trying to get the input events routed to the core keyboard. Do > > you know how that can be archieved? Right now they work just fine, but you > > have to open and process the relevant event* device to get the events... > > Yes, I found that KEY_POWER would be routed, but KEY_FN_F1 would not be. > I suspect something is filtering these keys. X probably doesn't know about those keys, thus doesn't pass them on. We need to use the proper keys where possible, using DMI matching if necessary. I'm sure the events get to the input device (ie. it shows up under evtest). -- Bastien Nocera <hadess@xxxxxxxxxx> ------------------------------------------------------------------------- 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
