xserver-xorg-input-evdev eats my eject key
john at Calva.COM
Sun Mar 9 13:49:21 PDT 2008
John Hughes wrote:
> Daniel Stone wrote:
>> On Sat, Mar 08, 2008 at 10:36:52AM +0100, John Hughes wrote:
>>> I've got a Sony Vaio TX3 laptop, with some extra buttons, [..]
>>> One of which has a "dvd eject" symbol on it. When pressed the keycode
>>> KEY_FN_E (0x1e1) is produced.
>>> After much debugging I've found that it gets at least as far as
>>> EvdevKeyProcess in evdev_key.c, but some time after that the key
>>> disappears into a black hole - xev &c don't see it.
>> Unfortunately this is next-to-impossible to do within the protocol:
>> (0x1e1 = 481)
> Oh what joy.
> So it seems the best thing would be to teach sony-laptop not to use
> keycodes > 255 (Like maybe it should be producing KEY_EJECTCD when I
> press the button with a nice "eject CD" label.
I've fixed this for my Vaio by putting:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<!-- These are buttons synthesized in the sony-laptop kernel module
You can find the scancodes in /usr/include/linux/sonypi.h -->
<match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" string_outof="VGN-TX3XP_B">
<append key="input.keymap.data" type="strlist">0x14:ejectcd</append> <!-- EjectCD key (not FN_E) -->
<append key="info.capabilities" type="strlist">input.keymap</append>
The comment "You can find the scancodes in /usr/include/linux/sonypi.h"
is rubbish. I'm still not sure why the EJECT button is getting scancode
0x14, looking at the sony-laptop.c and sonypi.h files it looks like it
should be 27 (0x1b).
The famous "keymap quirks" page,
gives no clues for finding scancodes that are mapped, but unusable by X.
More information about the xorg