evdev: support for touchscreens not providing BTN_TOUCH

[Peter Hutterer]

On Sun, May 22, 2011 at 10:53:37PM +0200, Peter Korsgaard wrote:
> >>>>> "Chris" == Chris Bagwell <chris at cnpbagwell.com> writes:
>  Chris> I don't think you can do much on xf86-input-evdev side to solve
>  Chris> this issue.  The HW designers attempted to default to something
>  Chris> so you could limp along until a custom driver can take over but
>  Chris> they made some bad choices.
> 
> Notice that this touchscreen works out of the box on Windows without any
> custom driver (just the standard HID).

We've had a discussion about this in September at a MT workshop and it's a
bit of a weak argument. AIUI, companies don't get the Win7 stamp of approval
if it doesn't work with the standard HID driver. And my guess is that the
standard HID driver is all but standard but merely the HID driver
forward-ported from Win(n-1), including several quirks that
have been there in the past - because removing those would break support for
older devices.
So we don't know what the windows standard HID driver does but we do know
that companies are unlikely to sell devices that don't work against that
driver. so standard HID is defined as "whatever Win7 accepts".

Really, hearing a sentence along the line of "we don't know what this HID
field is for either but we use it this way and Win7 accepts it" from a HW
person was quite interesting.

>  Chris> You can argue that xf86-input-evdev should be defaulting to
>  Chris> TOUCHPAD or TOUCHSCREEN anytime it it detects ABS_X and ABS_Y
>  Chris> but no REL_X and REL_Y.  That would get you a little further to
>  Chris> usability.  At least the cursor would move around.
> 
> Indeed.
> 
>  Chris> But then the hardware is sending a left button press when you touch
>  Chris> screen instead of a pressure or finger tip indication.  So you can
>  Chris> move the cursor around the screen but you'll constantly be dragging
>  Chris> stuff around or mis-selecting something.  There is nothing that
>  Chris> xf86-input-evdev can do short of adding an optional hack to treat
>  Chris> button press as finger pressure.
> 
> But we already convert BTN_TOUCH to BTN_LEFT in xf86-input-evdev?
> 
>         case BTN_TOUCH:
>             /* For devices that have but don't use proximity, use
>              * BTN_TOUCH as the proximity notifier */
>             if (!pEvdev->use_proximity)
>                 pEvdev->in_proximity = value ? ev->code : 0;
>             if (!(pEvdev->flags & (EVDEV_TOUCHSCREEN | EVDEV_TABLET)))
>                 break;
>             /* Treat BTN_TOUCH from devices that only have BTN_TOUCH as
>              * BTN_LEFT. */
>             ev->code = BTN_LEFT;
> 
> So it should afaik just work if we would default to touchscreen rather
> than mouse in this case.
> 
> Peter, would you accept a patch doing that?

yes, I think the best solution here would be to compare rel and abs axes and
prioritise the axes that have x/y over the ones that don't. which is a
general issue with evdev, the rel vs abs check is a bit too coarse. there
are axes that are more important than others.

Cheers,
  Peter
 
>  Chris> So in this case, its really best to get kernel side working right.
> 
> The controller uses the USB HID class, so there's no custom driver
> involved atm.