xserver-xorg-input-evdev eats my eject key

John Hughes 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:
>> http://bugs.freedesktop.org/show_bug.cgi?id=x11-keycode-limit
>>
>> (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 -*- -->

<deviceinfo version="0.2">
  <device>
    <!-- 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>
        </match>

In /etc/hal/fdi/information/30-keymap-module-sony-laptop.fdi

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, 
http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-intro.html, 
gives no clues for finding scancodes that are mapped, but unusable by X.




More information about the xorg mailing list