Chris Hanson wrote: > You need to use the input subsystem utilities (specifically, > input-kbd) to map the scan codes to particular keys. Thanks for the sample scripts, Chris. I cannot run the important part of them, though, because I have no input-kbd command, cannot find any Fedora package provides it, and cannot find sources for it either. :-( > I wish this was simpler, but there are still some rough edges. Actually, I think HAL is already trying to make this simpler. Take a look at <http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-input-keymap>, which includes the following description of the HAL "input.keymap.data" property: key: input.keymap.data type: strlist values: e.g. "e017:brightnessup" description: The scancode is represented in hex and the keycode name as a string. The keycode name is not case sensitive. On Linux, the keycode name should be the same constant as present in /usr/include/linux/input.h with the 'KEY_' prefix removed, e.g. 'KEY_SLEEP' -> 'sleep'. You can append as many input.keymap.data values as there are keys to remap. On my box, the HAL device representing "ThinkPad Extra Buttons" has an input.keymap.data property which includes "0x17:vendor". Mapping scancode 0x17 (for the ThinkVantage key) onto KEY_VENDOR seems pretty sensible to me. A quick look at the HAL sources shows that the values in input.keymap.data ultimately turn into EVIOCSKEYCODE ioctl() calls. So this property isn't just for decoration; it's genuinely being used to configure the input device's mappings. I can also confirm that hald is parsing the input.keymap.data property and then running the hal-setup-keymap helper program to do the actual input device mapping work. Perhaps the mappings are not actually being applied, or were applied but later erased. Is there a way to check the current mappings for a given input device? Perhaps the mappings are in place, but are never receiving that 0x17 scan code in the first place. How can I check whether that 0x17 is arriving at all? If it is arriving, then the problem is with the input device, the input device's mappings, or something that happens later on in user space. If that 0x17 scan code is not arriving in the first place, then the problem is with thinkpad_acpi or my configuration thereof. > PS: Many thanks to Henrique for implementing the input features in > thinkpad-acpi, nicely documenting it, and answering my questions as I > was figuring this out. Agreed. And many thanks to Henrique and you for the help you've both been giving me. Regards, Ben ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
