[Gta04-owner] X keycode of the Power/AUX buttons
Dr. H. Nikolaus Schaller
hns at goldelico.com
Sat Nov 12 08:35:24 CET 2011
Am 11.11.2011 um 17:09 schrieb Neil Jerram:
> On 11.11.2011 15:16, Dr. H. Nikolaus Schaller wrote:
>> I think I have pinned down the problem why the AUX button is
>> recognized as a mouse.
>> The evdev driver looks at the keycodes the driver can send. And counts the
>> number of "Mouse buttons". It assumes that the highest code it finds defines
>> the number of mouse buttons.
> Nice, thanks.
>> Now, our driver is configured in the boardfile to send a
>> .code = BTN_EXTRA,
>> I don't remember why... Maybe from copying some example code that was
>> for a mouse.
>> A better choice is to send KEY_OK (0x160).
>> There was another issue with evdev (which I would consider a bug). evdev
>> also looks for keys but only in keycode range 0 .. BTN_MISC-1 (=0xff). So we
>> need to add a dummy key in this range or evdev still does not recognize it as
>> a keyboard.
>> I still can't see an event printed by xev, although the xorg.log appears to
>> be ok. Maybe the KEY_OK button is not mapped to anything by default.
> I'm still not clear on whether and how there is a mapping from the values like KEY_OK that are fed _into_the_bottom_ of evdev, and the keycode values like <POWR> that come _out_of_the_top_ of evdev and feed into X.
Maybe it is this:
and there is some default mapping applied if none is explicitly specified.
> But whether it's mapped or not, in order to be usable at the X level, I think the top keycode value needs to be one of those listed in the XKB config as an evdev keycode, and which has an associated keysym.
> I'll try to have a look at this this evening - unless you've already sorted it all out by then :-)
But I did take a second look into the evdev.c code. And line 286 says:
/* The X server can't handle keycodes > 255. */
Then, I pressed the AUX button (KEY_OK) and did look into Xorg.0.log
and indeed found:
(WW) AUX Button: unable to handle keycode 352
Ok. So we can't use the nice keycodes like KEY_OK etc.
An obvious solution would be to send KEY_ENTER, which appears
to be ok for most situations - unless you connect a USB or Bluetooth
keyboard and want to distinguish between the AUX button and the
enter key of the keyboard.
So we need to choose a keycode that is rarely used on real keyboards
but still in the 1..255 range and has a useful meaning for the AUX button.
Some proposals from include/input.h plus my reasons:
KEY_F1 (or other F-Key) - trigger some function
KEY_SYSRQ - system request
KEY_MACRO - could be used to start a macro
KEY_MENU - usually used to open some menu
KEY_WAKEUP - counterpart to KEY_POWER
KEY_PROG1 (2, 3, 4) - programmable key
What do you think is the best choice?
We should find to some common definition to keep distributions
and configurations compatible without the need to change the
More information about the Gta04-owner