[Gta04-owner] X keycode of the Power button

[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.

> 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.

        Neil