[PATCH evdev 3/3] Allow relative scroll valuators on absolute devices

[Chase Douglas]

On 03/28/2012 10:30 PM, Peter Hutterer wrote:
> On Wed, Mar 28, 2012 at 08:19:00PM -0700, Chase Douglas wrote:
>> On 03/28/2012 05:09 PM, Peter Hutterer wrote:
>> * Are we going to pay later for having variables like "want_scroll_axes"
>> that configure axes like REL_DIAL? The variable is essentially
>> controlling a whitelist. 
> 
> Yes, but not too badly I hope. Changes in scroll axes are few, so I think we
> can live with this for now. Given how more and more devices move towards
> touch-based interfaces, I doubt we'll see any new axes that are dedicated
> towards scrolling in the near future.

How about going with the variable name "want_wheel_axes"? I just don't
like it controlling a "dial" non-scroll axis too.

>> Would we be better off having a default
>> blacklist to disable REL_X and REL_Y if ABS_X and ABS_Y are supported,
>> and letting everything else through?
> 
> evdev has a either rel or absolute axis policy for largely historical
> reasons. And the main reason is that I've seen devices that have both,
> usually (but not always!) at least one set of axes are partially mute.
> This is the main reason for the whole mess in evdev, I'd be glad to get rid
> of it.
> 
> Current servers _should_ be able to deal with relative events on
> absolute axes and vice versa, though this needs more testing and I haven't
> found the time to implement this yet.
> The next step then is to figure out if clients can deal with it correctly,
> having axis ranges for some axes but receiving values outside of it (my
> guess is 'yes' since synaptics has been doing this for a while now, but
> again this needs testing).
> 
> So yeah, this is a hack, but it fixes a serious problem in server 1.12 +
> evdev 2.7.0 and the only other solution is quite costly to implement.

Ok, sounds good to me.

[snip]

>>> @@ -1852,12 +1940,16 @@ static void
>>>  EvdevInitAnyValuators(DeviceIntPtr device, EvdevPtr pEvdev)
>>>  {
>>>      InputInfoPtr pInfo = device->public.devicePrivate;
>>> +    int rel_success = FALSE;
>>>  
>>>      if (pEvdev->flags & EVDEV_RELATIVE_EVENTS &&
>>>          EvdevAddRelValuatorClass(device) == Success)
>>> +    {
>>> +        rel_success = TRUE;
>>
>> The variable "rel_success" doesn't carry much connotation by itself. I
>> think "has_rel_axes" would be better.
> 
> I'll think of something, thanks.
> has_rel_axes is used elsewhere with a different meaning and I don't want to
> overload it either. this one here is really "relative axes successfully
> initialised?"

I worried about the name clash with has_rel_axes elsewhere too, but this
is a small function and it would be a local variable. My personal
opinion is that it's ok to clash like this. However, I understand if you
disagree :).

Maybe "rel_initialized"?

-- Chase