Also detect touchscreens identifying as mice

[SimonHyde-BBC]

Some touchscreens don't have a type of 'xi_touchscreen' but do have a calibartion matrix, so fall back on this property existing if we can't find anything that is an xi_touchscreen

[kreijack]

I am not against the idea, but I would like to know better the user case: which is the device that doesn't have type==xi_touchscreen but have a "libinput Calibration Matrix" property ?

More comments to the code.

[SimonHyde-BBC]

I've come across multiple integrated touchscreens in various models of all-in-one computers (such as the Asus ET1602) which identify as a type "MOUSE" (XI_MOUSE), but still have a calibartion matrix. I think these may be touchscreens that are configurable to present either mouse events (in which case they're seen as XI_MOUSE) or touch events (in which case they're XI_TOUCHSCREEN). With a version of xlibinput_calibrator tweaked to give the type in --list-devices, I see the following device. :

 11: HID TOUCH HID Touch Panel Mouse
        Type: MOUSE
        Coordinate Transformation Matrix: 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Enabled: 1
        Device Node: /dev/input/event7
        Device Product ID: 7165, 5768
        libinput Calibration Matrix: 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        libinput Calibration Matrix Default: 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        libinput Drag Lock Buttons:
        libinput Horizontal Scroll Enabled: 1
        libinput Left Handed Enabled: 0
        libinput Left Handed Enabled Default: 0
        libinput Middle Emulation Enabled: 0
        libinput Middle Emulation Enabled Default: 0
        libinput Natural Scrolling Enabled: 0
        libinput Natural Scrolling Enabled Default: 0
        libinput Send Events Mode Enabled: 0, 0
        libinput Send Events Mode Enabled Default: 0, 0
        libinput Send Events Modes Available: 1, 0

lsusb for this device returns:

Bus 001 Device 006: ID 1bfd:1688 TouchPack Resistive Touch Screen

I've seen these symptoms on multiple All-in-One computers, not just the example listed above.

[kreijack]

I've come across multiple integrated touchscreens in various models of all-in-one computers (such as the Asus ET1602) which identify as a type "MOUSE" (XI_MOUSE), but still have a calibartion matrix. I think these may be touchscreens that are configurable to present either mouse events (in which case they're seen as XI_MOUSE) or touch events (in which case they're XI_TOUCHSCREEN). With a version of xlibinput_calibrator tweaked to give the type in --list-devices, I see the following device. :

 11: HID TOUCH HID Touch Panel Mouse
[...]

lsusb for this device returns:

Bus 001 Device 006: ID 1bfd:1688 TouchPack Resistive Touch Screen

I've seen these symptoms on multiple All-in-One computers, not just the example listed above.

I am not sure if the presence of "libinput calibration matrix" is enough to allow to consider the device as "touchscreen". Looking a bit to the udev, it seems that a device to be declared as "touchscreen" have to have the BTN_TOUCH input event (See here).

What is the output of evtest /dev/input/input<nr> ? In my case I get

$ sudo evtest  /dev/input/event16
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1341 product 0x1 version 0x4
Input device name: "VirtualTouch"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     1023
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     1023
Properties:
  Property type 1 (INPUT_PROP_DIRECT)

I did a test in qemu, and I got an "absolute" mouse (i.e. ABS_Y and ABS_X and BTN_LEFT but not BTN_TOUCH). Frankly speaking I would treat these device as 'broken'; we can make a database of exceptions (on the basis of the USB id) considering these as touchscreen even if declared as 'mouse'. What do you think ?

[SimonHyde-BBC]

I am not sure if the presence of "libinput calibration matrix" is enough to allow to consider the device as "touchscreen". Looking a bit to the udev, it seems that a device to be declared as "touchscreen" have to have the BTN_TOUCH input event (See here).

That sounds quite plausible. It's quite common for touchscreen devices to be configurable as to whether they generate mouse left/right button events, or BTN_TOUCH events, this allows them to work better with legacy applications and devices not designed for touch events. For example on Windows, if you connect a HID touchscreen that generates touch events, and run up a legacy application that expects Mouse Down and Mouse Up events, then you Windows will emulate those events by waiting until the Touch Release event, and at that point generating a Mouse Down immediately followed by a Mouse Up event. This makes it impossible to do a "press and hold" user interaction on legacy applications. I don't think Windows even natively supported BTN_TOUCH events before Windows 7, so there will be older devices out there that wanted to work with Windows without extra drivers that generate BTN_LEFT events instead.

Obviously this example doesn't relate directly relate to what we're trying to do here (it's a completely different operating system, for starters!), but it does explain why touchscreen manufacturers make devices which can be switched to generating BTN_LEFT events instead of BTN_TOUCH events. I'm fairly sure there will be some proprietary manufacturer software for this touchscreen that can switch it between the 2 modes.

What is the output of evtest /dev/input/input<nr> ?

Well, that almost complicates matters even more, evtest lists 2 /dev/input/event for this device:

/dev/input/event4:      HID TOUCH HID Touch Panel
/dev/input/event5:      HID TOUCH HID Touch Panel Mouse

/dev/input/event4 does present properties claiming it can generate BTN_TOUCH:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1bfd product 0x1688 version 0x101
Input device name: "HID TOUCH HID Touch Panel"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 320 (BTN_TOOL_PEN)
    Event code 330 (BTN_TOUCH)
    Event code 331 (BTN_STYLUS)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     4095
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     4095
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
  Property type 1 (INPUT_PROP_DIRECT)

But this device never generates any actual events to evtest when you touch the screen, and isn't exposed by libinput/xinput

/dev/input/event5, on the other hand, does generate events and is exposed by libinput/xinput:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1bfd product 0x1688 version 0x101
Input device name: "HID TOUCH HID Touch Panel Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   2582
      Min        0
      Max     4095
    Event code 1 (ABS_Y)
      Value    903
      Min        0
      Max     4095
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:

I did a test in qemu, and I got an "absolute" mouse (i.e. ABS_Y and ABS_X and BTN_LEFT but not BTN_TOUCH). Frankly speaking I would treat these device as 'broken'; we can make a database of exceptions (on the basis of the USB id) considering these as touchscreen even if declared as 'mouse'. What do you think ?

I'd say it isn't broken, it's a desirable feature of touch devices to be able generate BTN_LEFT instead of BTN_TOUCH for legacy applications that deal better with them. It feels like a calibrator should be able to calibrate any device which can generate absolute X/Y co-ordinates, not just more modern devices which generate "new" BTN_TOUCH events.

The system I'm developing needs to "just work" on a wide variety of old and new hardware. Rather than explicitly listing USB ids of devices, it feels like my original proposal works well for this requirement: Try to detect touchscreens that generate BTN_TOUCH events, but if there aren't any, fall back to seeing if there's a single calibratable device instead.

[kreijack]

/dev/input/event4 does present properties claiming it can generate BTN_TOUCH:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1bfd product 0x1688 version 0x101
Input device name: "HID TOUCH HID Touch Panel"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 320 (BTN_TOOL_PEN)
    Event code 330 (BTN_TOUCH)
    Event code 331 (BTN_STYLUS)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     4095
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     4095
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
  Property type 1 (INPUT_PROP_DIRECT)

Now I am confused: event4 having EV_ABS and BTN_TOUCH should be detected as touchscreen; this means that it should be poked by xlibinput_calibrator as touchscreen; of course this is not the case otherwise it would be not enough to poke a device with a 'libinput matrix calibration' when we don't find a touchscreen device...

[SimonHyde-BBC]

Ah, yes, I had a feeling I shouldn't mention that, because it just confuses matter....Whilst evtest lists this device, it doesn't get exposed by libinput or X, and even with evtest, it never actually produces any events (but you can see events for touches coming out of the other device). I think this device is basically de-activated in some way, and may become activated if the device switches to the other mode.

Anyway, I don't see why we shouldn't be detecting calibratable "mice" if there are no calibratable "touchscreens" available, it seems a fairly sane fallback, given that such devices clearly exist in the wild.

[kreijack]

Ah, yes, I had a feeling I shouldn't mention that, because it just confuses matter....Whilst evtest lists this device, it doesn't get exposed by libinput or X, and even with evtest, it never actually produces any events (but you can see events for touches coming out of the other device). I think this device is basically de-activated in some way, and may become activated if the device switches to the other mode.

Strange; my understanding is that the hwdb of udev filters these devices, disabling when needed.

Anyway, I don't see why we shouldn't be detecting calibratable "mice" if there are no calibratable "touchscreens" available, it seems a fairly sane fallback, given that such devices clearly exist in the wild.

This kind of exception should be handled at hwdb level. We can solve this, as your suggested, updating xlibinput_calibrator. However updating hwdb will solve this even for other SW.

Let me to review your patch, and I will integrate in xlibinput_calibrator.

[kreijack]

I merged your code, and I released the v0.12. Let me know if this solve your issue.