evdev: support for touchscreens not providing BTN_TOUCH

[Chris Bagwell]

On Fri, May 20, 2011 at 8:08 AM, Peter Korsgaard <jacmet at sunsite.dk> wrote:
> Hi,
>
> I've recently tested a lumio crystaltouch touchscreen on Linux, and
> xf86-input-evdev unfortunately gets confused and handles it as a mouse.
>
> It provides the following events:
>
> Input driver version is 1.0.1
> Input device ID: bus 0x3 vendor 0x202e product 0x5 version 0x111
> Input device name: "LUMIO Inc LUMIO CrystalTouch ver 1.1C"
> Supported events:
>  Event type 0 (Sync)
>  Event type 1 (Key)
>    Event code 272 (LeftBtn)
>    Event code 273 (RightBtn)
>    Event code 274 (MiddleBtn)
>  Event type 2 (Relative)
>    Event code 9 (Misc)
>  Event type 3 (Absolute)
>    Event code 0 (X)
>      Value    650
>      Min        0
>      Max     4095
>    Event code 1 (Y)
>      Value   3221
>      Min        0
>      Max     4095
>  Event type 4 (Misc)
>    Event code 4 (ScanCode)
> Testing ... (interrupt to exit)
> Event: time 1305882024.934011, type 4 (Misc), code 4 (ScanCode), value 90001
> Event: time 1305882024.934017, type 1 (Key), code 272 (LeftBtn), value 1
> Event: time 1305882024.934029, type 3 (Absolute), code 0 (X), value 270
> Event: time 1305882024.934034, type 3 (Absolute), code 1 (Y), value 1513
> Event: time 1305882024.934039, type 2 (Relative), code 9 (Misc), value 1
> Event: time 1305882024.934043, -------------- Report Sync ------------
> Event: time 1305882024.943019, type 2 (Relative), code 9 (Misc), value 1
> Event: time 1305882024.943025, -------------- Report Sync ------------
> Event: time 1305882024.951998, type 3 (Absolute), code 0 (X), value 275
> Event: time 1305882024.952006, type 3 (Absolute), code 1 (Y), value 1519
> Event: time 1305882024.952010, type 2 (Relative), code 9 (Misc), value 1
>
> Whichs leads to evdev configuring it as a mouse as there's no BTN_TOUCH:
>
> [   563.001] (**) LUMIO Inc LUMIO CrystalTouch ver 1.1C: always reports core events
> [   563.001] (**) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Device: "/dev/input/event17"
> [   563.020] (--) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Found 3 mouse buttons
> [   563.020] (--) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Found relative axes
> [   563.020] (--) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Found absolute axes
> [   563.020] (--) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Found x and y absolute axes
> [   563.020] (II) LUMIO Inc LUMIO CrystalTouch ver 1.1C: Configuring as mouse
> [   563.020] (**) LUMIO Inc LUMIO CrystalTouch ver 1.1C: YAxisMapping: buttons 4 and 5
> [   563.020] (**) LUMIO Inc LUMIO CrystalTouch ver 1.1C: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> [   563.020] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.2/input/input19/event17"
> [   563.020] (II) XINPUT: Adding extended input device "LUMIO Inc LUMIO CrystalTouch ver 1.1C" (type: MOUSE)
>
> So the absolute X/Y coordinates gets ignored and the REL_MISC event gets
> handled as a relative motion of +1 in X direction - Not quite what we
> want.
>

I don't think you can do much on xf86-input-evdev side to solve this
issue.  The HW designers attempted to default to something so you
could limp along until a custom driver can take over but they made
some bad choices.

You can argue that xf86-input-evdev should be defaulting to TOUCHPAD
or TOUCHSCREEN anytime it it detects ABS_X and ABS_Y but no REL_X and
REL_Y.  That would get you a little further to usability.  At least
the cursor would move around.

But then the hardware is sending a left button press when you touch
screen instead of a pressure or finger tip indication.  So you can
move the cursor around the screen but you'll constantly be dragging
stuff around or mis-selecting something.  There is nothing that
xf86-input-evdev can do short of adding an optional hack to treat
button press as finger pressure.

So in this case, its really best to get kernel side working right.

Also, its halfheartedly trying to advertise itself as a touchpad so
redirecting to xf86-input-synaptics would almost be an option but that
driver refusing to work with any touchpad that doesn't also support
pressure or tip events; and for good reason.

Chris