On Mon, 21 May 2007, Richard Hughes wrote: > > > 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. There is no way around that. It is how these things work. You are actually requesting to the firmware that "OSI will handle these hotkeys". And I suspect we are missing part of the interface on the X60 new BIOS, too. Is a X60 onwer up to some DSDT debugging ? > Sure, I think only KEY_FN_HOME and KEY_FN_END are needed for my X60. Also KEY_FN_BACKSPACE, KEY_FN_INSERT and KEY_FN_DELETE, if it is anything like the T43. > 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. Won't help. Many of these keys have no set meaning. > > 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. I will check more on this later. > > It is already working on 2.6.20, though, with some rough edges on the > > keycode remap sysfs interface (it requires binary attributes, which I am > > dealing with for the first time in my life). > > What is the keycode-remap interface? Do you mean using something like a > kernel version of KDSETKEYCODE? It is a binary attribute, that looks like a little-endian file composed of u16 values. Read from it to get the current hotkey->keycode map, write to it to change the mapping. There are 16 keycodes right now, but if we find out the hotkey interface in ACPI can be extended, it will grow. KEY_RESERVED disables the issuing of input events for that key. Anything else (valid) enables it, including KEY_UNKNOWN. Would HAL need to mess with these? If it does, it means I need to add a lock attribute that disables changes to it (which HAL is *not* allowed to touch) so as to allow the admin to preserve his setup. > Also, is the aim to deprecate or remove the hotkey events, or shall I > add workarounds to HAL so we don't get double events? There is a bit of a problem. The ACPI hotkey events are complete, and can handle *anything* the firmware produces as long as there is code in thinkpad-acpi to intercept the events. Is there an event we can send through the input layer capable of carrying a 16-bit value ? Otherwise, I can remove the ACPI events, but I'd have to add generic uevents to replace them. As for double event suppresion, it is probably best if we make it in-kernel. It really doesn't make much sense to generate both events, but at the same time, I don't want to break existing systems. It probably makes sense to suppress ACPI events to any hotkets mapped to a non-KEY_RESERVED keycode if the input device is open by default, with some sort of sysfs override for this. Would that work? HAL is not to touch the override, of course. -- "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
