[Gta04-owner] X keycode of the Power/AUX buttons

NeilBrown neilb at suse.de
Sat Nov 12 10:05:40 CET 2011


On Sat, 12 Nov 2011 09:55:32 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 
> Am 12.11.2011 um 08:35 schrieb Dr. H. Nikolaus Schaller:
> 
> > 
> > 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
> >>> intended
> >>> 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:
> > 
> > http://www.freedesktop.org/wiki/Software/XKeyboardConfig
> > 
> > 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 :-)
> > 
> > not yet...
> > 
> > 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?
> 
> Maybe the best choice is to do it identical to the GTA02.
> 
> Who knows the kernel key code of the GTA02?

Power button returns code 116 - Power
AUX button returns  code 169 - Phone
The head-set button returns code 207 - Play

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20111112/87289047/attachment.bin>


More information about the Gta04-owner mailing list