[Gta04-owner] X keycode of the Power/AUX buttons
Dr. H. Nikolaus Schaller
hns at goldelico.com
Fri Nov 11 16:16:12 CET 2011
Am 11.11.2011 um 14:30 schrieb Dr. H. Nikolaus Schaller:
> Am 09.11.2011 um 12:10 schrieb Neil Jerram:
>> On 09.11.2011 10:13, Dr. H. Nikolaus Schaller wrote:
>>>> (**) 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.
>> Thanks, that would be good to check.
> I could not find anything problematic in the kernel driver.
> I have also compared the twl_powerbutton driver but it does nothing obviously
> different in its probe() function.
> But it appears to be a common problem on ARM-OMAP handhelds:
> Maybe we have to dig into the evdev driver source to find out how it detects
> if the device is a keyboard or a mouse. Maybe, the gpio-keys driver is too old
> to supply some important bit or flag (ioctl?).
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.
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
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.
The next step is to update the (hw-validation) kernel sources and make a
new release asap (that also fixes the accept4 system call and some other
minor issues). I'll give a note when done.
More information about the Gta04-owner