[Gta04-owner] X keycode of the Power button

[Dr. H. Nikolaus Schaller]

Am 09.11.2011 um 00:34 schrieb Neil Jerram:

> On 07.11.2011 14:21, Dr. H. Nikolaus Schaller wrote:
>> Hi Neil,
>> 
>> Am 07.11.2011 um 14:59 schrieb Neil Jerram:
>> 
>>> Hello all...
>>> 
>>> I'm playing with UIs on my GTA04, and having trouble binding an action to the Power button.  The problem seems to be a misunderstanding somewhere about what the right keycode is for the Power button.
>>> 
>>> When I run xev and press the Power button, xev says that the keycode is 124, and the keysym is XF86PowerOff.  But if I bind XF86PowerOff to an action in matchbox-window-manager's config, and run matchbox-window-manager with debugging enabled, its output indicates that it has mapped XF86PowerOff to keycode 222.  Therefore matchbox grabs keycode 222, and the result is that nothing happens when I press the button, presumably because the keycode is really 124.
> 
> Wowzah!  After oodles of looking at and gradually partially understanding XKB doc, I've actually found the solution; I can hardly believe it :-)
> 
> It's a server bug.  A similar problem is described at https://bugzilla.redhat.com/show_bug.cgi?id=508434, and the solution is just "setxkbmap -layout us".
> 
> The "setxbdmap ..." needs to be after X has started up but before anything relevant (such as matchbox in my case) calls XKeysymToKeycode; near the top of /.xsession works.
> 
> The XKB layout on GTA04 is already "us", so the "setkbdmap ..." is conceptually a no-op, but in fact it works around the bug.

Fine!

> 
>> I think the keycode is defined in the kernel
>> /drivers/input/misc/twl4030-pwrbutton.c):
>> 
>> 	input_report_key(pwr, KEY_POWER, value & PWR_PWRON_IRQ);
>> 
>> I.e. there is an input event for key KEY_POWER. This is defined in
>> include/linux/input.h:
>> 
>> 	#define KEY_POWER		116	/* SC System Power Down */
>> 
>> So we have a third definition...
>> 
>> You could also try
>> 
>> 	http://packages.debian.org/squeeze/evtest
>> 
>> Which should show the raw events.
> 
> Indeed, using evtest is rather nicer than just "cat".  Thanks for the tip.
> 
>>> Finally, another problem is that even after the additions above, pressing the AUX button doesn't cause any xev output at all.  Do I need to do something else to get it plumbed through to X?  Note that I do see stuff if I do "cat /dev/input/event0" and then press AUX, so physically and electronically the button is working.
>> 
>> 
>> This appears to indicate that there is one more mapping table between
>> /dev/input/event and xmodmap/xev.
> 
> Or between /dev/input/event and evdev, I think.  Also I noticed in Xorg.0.log:
> 
> (**) AUX Button: always reports core events
> (**) AUX Button: Device: "/dev/input/event0"
> (II) AUX Button: Found 9 mouse buttons
> (II) AUX Button: Configuring as mouse
> (**) AUX Button: YAxisMapping: buttons 4 and 5
> (**) AUX Button: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> (II) XINPUT: Adding extended input device "AUX Button" (type: MOUSE)
> 
> So for some reason either the kernel or evdev thinks that AUX is a mouse - that's the next thing to investigate.

Oops - maybe we define a mouse driver instead of a GPIO keyboard driver...
This may be some misconfiguration in the kernel. I will give it a look in the
next days.

Nikolaus