From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Fri, 5 Nov 2010 17:49:44 +1100

On 5 November 2010 17:27, Magnus Holmgren <magnushol_at_gmail.com> wrote:
> On Thu, Nov 4, 2010 at 21:43, Thomas Martitz
> <thomas.martitz_at_student.htw-berlin.de> wrote:
>
>> Scrollwheels are different. The buttons are posted off the normal
>> button_tick() code, the drivers post to the button queue on their own (with
>> acceleration as extra data). And they never post BUTTON_REL, only
>> BUTTON_SCROLL_FWD or BUTTON_SCROLL_FWD|BUTTON_REPEAT (same for
>> BUTTON_SCROLL_BACK).
>
> Yes, I saw that. But if the release event of the most recent button
> press wasn't posted _and_ there is a context change (e.g., dropping
> out of WPS), then get_action_worker swallows all wheel events in the
> following if statement:
>
>    if ((context != last_context) && ((last_button & BUTTON_REL) == 0))
>    {
>        if (button & BUTTON_REL)
>        {
>            last_button = button;
>            last_action = ACTION_NONE;
>        }
>        /* eat all buttons until the previous button was |BUTTON_REL
>           (also eat the |BUTTON_REL button) */
>        return ACTION_NONE; /* "safest" return value */
>    }
>
> Making sure button release events always are posted seems to fix that.
>
> --
>   Magnus
>

I hit this issue with the recent android button handling reworking.
not sending a BUTTON_REL is only a problem is the button can cause a
context (screen) change. So, how can that happen with the scroll
wheel?
I worked around this on android by only posting the BUTTON_REL event
on the android dpad (which I'm hoping is safe on all targets but
probably isnt). A proper way to handle these buttons/wheels would be
very welcome
Received on 2010-11-05