[PATCH evdev 1/2] Force x/y axes to exist on devices with any other axes (#44655)

[Chase Douglas]

On 01/13/2012 09:46 AM, Peter Hutterer wrote:
> On 13/01/12 18:00 , Chase Douglas wrote:
>> On 01/13/2012 01:18 AM, Peter Hutterer wrote:
>>> Too much in the server relies on x/y to exist and to be axes 0 and 1. So if
>>> any relative axes exist, initialize REL_X/Y or ABS_X/Y as well.
>>>
>>> For servers up to 1.11: a scrollwheel-only device now has relative axes
>>> where it only had buttons before.
>>>
>>> For servers 1.12 or later: the device now has x/y in addition to the scroll
>>> axes.
>>>
>>> X.Org Bug 44655<http://bugs.freedesktop.org/show_bug.cgi?id=44655>
>>>
>>> Signed-off-by: Peter Hutterer<peter.hutterer at who-t.net>
>>> ---
>>>   src/evdev.c |   43 +++++++++++++++++++++++++++++++++++++++++++
>>>   1 files changed, 43 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/evdev.c b/src/evdev.c
>>> index 989a255..68e3c75 100644
>>> --- a/src/evdev.c
>>> +++ b/src/evdev.c
>>> @@ -1958,6 +1958,38 @@ EvdevGrabDevice(InputInfoPtr pInfo, int grab, int ungrab)
>>>       return TRUE;
>>>   }
>>>
>>> +/**
>>> + * Some devices only have other axes (e.g. wheels), but we
>>> + * still need x/y for these. The server relies on devices having
>>> + * x/y as axes 0/1 and core/XI 1.x clients expect it too (#44655)
>>> + */
>>> +static void
>>> +EvdevForceXY(InputInfoPtr pInfo, int mode)
>>> +{
>>> +    EvdevPtr pEvdev = pInfo->private;
>>> +
>>> +    xf86IDrvMsg(pInfo, X_INFO, "Forcing %s x/y axes to exist.\n",
>>> +                (mode == Relative) ? "relative" : "absolute");
>>> +
>>> +    if (mode == Relative)
>>> +    {
>>> +        EvdevSetBit(pEvdev->rel_bitmask, REL_X);
>>> +        EvdevSetBit(pEvdev->rel_bitmask, REL_Y);
>>> +    } else if (mode == Absolute)
>>> +    {
>>> +        EvdevSetBit(pEvdev->abs_bitmask, ABS_X);
>>> +        EvdevSetBit(pEvdev->abs_bitmask, ABS_Y);
>>> +        pEvdev->absinfo[ABS_X].minimum = 0;
>>> +        pEvdev->absinfo[ABS_X].maximum = 1000;
>>> +        pEvdev->absinfo[ABS_X].value = 0;
>>> +        pEvdev->absinfo[ABS_X].resolution = 0;
>>> +        pEvdev->absinfo[ABS_Y].minimum = 0;
>>> +        pEvdev->absinfo[ABS_Y].maximum = 1000;
>>> +        pEvdev->absinfo[ABS_Y].value = 0;
>>> +        pEvdev->absinfo[ABS_Y].resolution = 0;
>>> +    }
>>> +}
>>> +
>>>   static int
>>>   EvdevProbe(InputInfoPtr pInfo)
>>>   {
>>> @@ -2043,6 +2075,8 @@ EvdevProbe(InputInfoPtr pInfo)
>>>               pEvdev->num_buttons = num_buttons;
>>>           }
>>>
>>> +        EvdevForceXY(pInfo, Relative);
>>> +
>>>           if (!ignore_rel)
>>>           {
>>>               xf86IDrvMsg(pInfo, X_PROBED, "Found relative axes\n");
>>> @@ -2116,7 +2150,16 @@ EvdevProbe(InputInfoPtr pInfo)
>>>                       pEvdev->flags |= EVDEV_TOUCHSCREEN;
>>>                       pEvdev->flags |= EVDEV_BUTTON_EVENTS;
>>>               }
>>> +        } else {
>>> +#ifdef MULTITOUCH
>>> +            if (!EvdevBitIsSet(pEvdev->abs_bitmask, ABS_MT_POSITION_X) ||
>>> +                !EvdevBitIsSet(pEvdev->abs_bitmask, ABS_MT_POSITION_Y))
>>> +#endif
>>> +                EvdevForceXY(pInfo, Absolute);
>>>           }
>>> +
>>> +
>>> +
>>>       }
>>>
>>>       for (i = 0; i<  BTN_MISC; i++) {
>>
>> What ensures that the X and Y values of events are set for events? Or,
>> how are events delivered in the server if X and Y are always 0?
> 
> unless we have a bug in the server, we can handle events without x/y 
> set. if none are ever sent, last.valuators is taken from the sprite 
> position on the device changed event handling (and rescaled into device 
> range). root x/y is taken from those then.
> 
> so in this case, since the valuator mask should never have 0/1 set, 
> we're fine.

Ok

Reviewed-by: Chase Douglas <chase.douglas at canonical.com>