Summary: | External Thinkpad USB keyboard Fn buttons not working | ||
---|---|---|---|
Product: | hal | Reporter: | Rui Tiago Matos <tiagomatos> |
Component: | hal-info | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | martin.pitt, richard |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | FDI file to remap the keys |
Description
Rui Tiago Matos
2008-12-10 17:11:46 UTC
(In reply to comment #0) > Actually the sound volume up/down/mute, sleep ... already work. I suppose I'm hitting bug #11227 since the keys that work have a keycode <= 255, right? Is there a way to get around this? lshal output for the event8 device which gets the Fn keys' events: udi = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if1_logicaldev_input' info.addons.singleton = {'hald-addon-input'} (string list) info.callouts.add = {'fedora-setup-keyboard'} (string list) info.capabilities = {'input', 'input.keys', 'button'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if1' (string) info.product = 'Lite-On Tech IBM USB Travel Keyboard with UltraNav' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if1_logicaldev_input' (string) input.device = '/dev/input/event8' (string) input.originating_device = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if1' (string) input.product = 'Lite-On Tech IBM USB Travel Keyboard with UltraNav' (string) input.x11_driver = 'evdev' (string) input.xkb.layout = 'us' (string) input.xkb.model = 'pc105+inet' (string) input.xkb.rules = 'base' (string) linux.device_file = '/dev/input/event8' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2/5-2.3/5-2.3:1.1/input/input8/event8' (string) lshal output for the event7 device which gets the regular keys' events: udi = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if0_logicaldev_input' info.addons.singleton = {'hald-addon-input'} (string list) info.callouts.add = {'fedora-setup-keyboard'} (string list) info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if0' (string) info.product = 'Lite-On Tech IBM USB Travel Keyboard with UltraNav' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if0_logicaldev_input' (string) input.device = '/dev/input/event7' (string) input.originating_device = '/org/freedesktop/Hal/devices/usb_device_4b3_3019_noserial_if0' (string) input.product = 'Lite-On Tech IBM USB Travel Keyboard with UltraNav' (string) input.x11_driver = 'evdev' (string) input.xkb.layout = 'us' (string) input.xkb.model = 'pc105+inet' (string) input.xkb.rules = 'base' (string) linux.device_file = '/dev/input/event7' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2/5-2.3/5-2.3:1.0/input/input7/event7' (string) Created attachment 22783 [details]
FDI file to remap the keys
I've tried to make it work by doing a remap with a hal fdi file using the thinkpad one as reference but I've got 3 problems:
1. It doesn't actually work. Lines like this are appended to the X server log:
(WW) Lite-On Tech IBM USB Travel Keyboard with UltraNav: unable to handle keycode 265
2. The matching rule, as it is, will match both the regular keyboard's device and the Fn keys' device and adds the mapping to both.
3. I'm not sure how to name the file.
> 1. It doesn't actually work. Lines like this are appended to the X server log: Right now, X.org can only handle key codes up to 255, see bug 11227. If you find a key code < 256 which has a very similar meaning, then use that instead. Otherwise, we can still add the mapping, so that future X.org versions can handle it then. > 2. The matching rule, as it is, will match both the regular keyboard's device > and the Fn keys' device and adds the mapping to both. I guess you only want the mapping on the device which has the Fn keys? Unfortunately you didn't attach your complete lshal output, but try adding this after your first <match> rule (and append another </match>, of course): <match key="@info.parent:usb.interface.number" int="1"> > 3. I'm not sure how to name the file. Don't worry about that. It will be integrated into the existing files, the committer can do that easily. (In reply to comment #6) > > 1. It doesn't actually work. Lines like this are appended to the X server log: > > Right now, X.org can only handle key codes up to 255, see bug 11227. If you > find a key code < 256 which has a very similar meaning, then use that instead. > Otherwise, we can still add the mapping, so that future X.org versions can > handle it then. Shouldn't the FDI file I attached do that remaping already? The drawings on the keys and their positions are like any Thinkpad laptop's. It's the key codes that are apparently different but I thought the mapping I did was already enough. For instance: ... 0x10f:screenlock ... shouldn't this map the key code value 0x10f (271) to the value 152? I thought this would make hal configure the kernel so that the X server only saw the code 152. Yes, 152 will work, but in the X.org log you mentioned a key code "265", which doesn't work with X.org right now (for a different key, I suppose). (In reply to comment #8) > Yes, 152 will work, but in the X.org log you mentioned a key code "265", which > doesn't work with X.org right now (for a different key, I suppose). Then I don't know what's happening because those key codes being logged by the X server only show up when I have this FDI file in use. /me is confused. Thanks for the help Martin. Right, your fdi e. g. does <append key="input.keymap.data" type="strlist">0x10c:zoom</append> <!-- Fn+Space --> and /usr/include/linux/input.h shows that as #define KEY_ZOOM 0x174 which is way bigger than 256 (0x100). Thus you can't use the zoom key under X.org. Likewise with KEY_RADIO (0x181) and KEY_VENDOR, and perhaps others. So don't get me wrong, the .fdi is fine in that regard, you just can't use those keys. E. g. "vendor" can be replaced with "prog1" to make the key useful. It just needs the additional <match> on the interface number (which I can't test here). (In reply to comment #10) > Right, your fdi e. g. does > > <append key="input.keymap.data" type="strlist">0x10c:zoom</append> <!-- > Fn+Space --> > > and /usr/include/linux/input.h shows that as > > #define KEY_ZOOM 0x174 > > which is way bigger than 256 (0x100). Thus you can't use the zoom key under > X.org. Likewise with KEY_RADIO (0x181) and KEY_VENDOR, and perhaps others. > > So don't get me wrong, the .fdi is fine in that regard, you just can't use > those keys. E. g. "vendor" can be replaced with "prog1" to make the key useful. OK, I see now. I just assumed that as those names were used in the thinkpad fdi file they would be working (I don't actually have a thinkpad laptop). Anyway, other names like 'brightnessup' and 'brightnessdown' map to values 225 and 224 and should therefore work. Instead, I'm getting (for those key presses): (WW) Lite-On Tech IBM USB Travel Keyboard with UltraNav: unable to handle keycode 265 (WW) Lite-On Tech IBM USB Travel Keyboard with UltraNav: unable to handle keycode 264 Clearly, something is wrong. Don't know how or where but this was fixed at some point. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.