GNOME Bugzilla – Bug 757358
single touch devices are not detected as touch devices
Last modified: 2015-11-17 15:24:27 UTC
I spoke with Peter Hutterer about the no-kinetic-scrolling on touchscreen issue. The issue is that only multi-touch devices emit XITouchClass events. To detect a single-touch touchscreen, one cannot rely on XITouchClass. on IRC the following approach was discussed: <garnacho_> Oli747: hmm, abs x/y and GDK_SOURCE_MOUSE don't really mix together, I guess I could do such check as a last resort The single-touch-device I own is a PiTFT (a 2.8" resistive touchscreen from adafruit designed for the raspberry pi). Device information is here: $ xinput list-props 6 Device 'stmpe-ts': Device Enabled (112): 1 Coordinate Transformation Matrix (113): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (233): 0 Device Accel Constant Deceleration (234): 1.000000 Device Accel Adaptive Deceleration (235): 1.000000 Device Accel Velocity Scaling (236): 10.000000 Device Product ID (237): 0, 0 Device Node (238): "/dev/input/event0" Evdev Axis Inversion (239): 0, 0 Evdev Axis Calibration (240): 3800, 200, 200, 3800 Evdev Axes Swap (241): 1 Axis Labels (242): "Abs X" (230), "Abs Y" (231), "Abs Pressure" (232) Button Labels (243): "Button Unknown" (229), "Button Unknown" (229), "Button Unknown" (229), "Button Wheel Up" (118), "Button Wheel Down" (119) Evdev Middle Button Emulation (244): 0 Evdev Middle Button Timeout (245): 50 Evdev Third Button Emulation (246): 1 Evdev Third Button Emulation Timeout (247): 750 Evdev Third Button Emulation Button (248): 3 Evdev Third Button Emulation Threshold (249): 30 Evdev Wheel Emulation (250): 0 Evdev Wheel Emulation Axes (251): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (252): 10 Evdev Wheel Emulation Timeout (253): 200 Evdev Wheel Emulation Button (254): 4 Evdev Drag Lock Buttons (255): 0 pi@raspberrypi ~ $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ stmpe-ts id=6 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] pi@raspberrypi ~ $ xinput list 6 stmpe-ts id=6 [slave pointer (2)] Reporting 4 classes: Class originated from: 6. Type: XIButtonClass Buttons supported: 5 Button labels: "Button Unknown" "Button Unknown" "Button Unknown" "Button Wheel Up" "Button Wheel Down" Button state: Class originated from: 6. Type: XIValuatorClass Detail for Valuator 0: Label: Abs X Range: 0.000000 - 4095.000000 Resolution: 0 units/m Mode: absolute Current value: 960.000000 Class originated from: 6. Type: XIValuatorClass Detail for Valuator 1: Label: Abs Y Range: 0.000000 - 4095.000000 Resolution: 0 units/m Mode: absolute Current value: 2757.000000 Class originated from: 6. Type: XIValuatorClass Detail for Valuator 2: Label: Abs Pressure Range: 0.000000 - 255.000000 Resolution: 0 units/m Mode: absolute Current value: 0.000000 $ evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 Input device name: "stmpe-ts" 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 2624 Min 0 Max 4095 Event code 1 (ABS_Y) Value 2956 Min 0 Max 4095 Event code 24 (ABS_PRESSURE) Value 0 Min 0 Max 255 Properties: Testing ... (interrupt to exit)
Created attachment 314474 [details] [review] x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN Those won't have ABS_MT_* axes, so won't be reported has having XITouchClassInfo. Fallback on these to checking whether abs x/y axes are available. After the Wacom checks, any remaining device with absolute axes should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on devices with relative axes.
Review of attachment 314474 [details] [review]: Looks good to me… ::: gdk/x11/gdkdevicemanager-xi2.c @@ +321,3 @@ + + if (class->mode == XIModeAbsolute && + abs_y = gdk_x11_get_xatom_by_name_for_display (display, "Abs Y"); You probably want to check that you have *both* axes — even though I'm struggling to think of a device that exposes one absolute axis and not the other.
(In reply to Emmanuele Bassi (:ebassi) from comment #2) > Review of attachment 314474 [details] [review] [review]: > > Looks good to me… > > ::: gdk/x11/gdkdevicemanager-xi2.c > @@ +321,3 @@ > + > + if (class->mode == XIModeAbsolute && > + abs_y = gdk_x11_get_xatom_by_name_for_display (display, "Abs Y"); > > You probably want to check that you have *both* axes — even though I'm > struggling to think of a device that exposes one absolute axis and not the > other. Yeah I don't think there are :) (other extra axes are usually z/wheel/throttle...). Future devices might prove us wrong though :P Updated patch coming.
Created attachment 314484 [details] [review] x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN Those won't have ABS_MT_* axes, so won't be reported has having XITouchClassInfo. Fallback on these to checking whether abs x/y axes are available. After the Wacom checks, any remaining device with absolute axes should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on devices with relative axes.
Review of attachment 314484 [details] [review]: sure
Attachment 314484 [details] pushed as 29dd395 - x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN
I'm sorry to disappoint you but VMware is doing weird things :-( $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ VMware VMware Virtual USB Mouse id=7 [slave pointer (2)] ⎜ ↳ VirtualPS/2 VMware VMMouse id=9 [slave pointer (2)] ⎜ ↳ VirtualPS/2 VMware VMMouse id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=8 [slave keyboard (3)] $ xinput list 10 VirtualPS/2 VMware VMMouse id=10 [slave pointer (2)] Reporting 3 classes: Class originated from: 10. Type: XIButtonClass Buttons supported: 5 Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" Button state: Class originated from: 10. Type: XIValuatorClass Detail for Valuator 0: Label: Abs X Range: 0.000000 - 65535.000000 Resolution: 0 units/m Mode: absolute Current value: 33060.000000 Class originated from: 10. Type: XIValuatorClass Detail for Valuator 1: Label: Abs Y Range: 0.000000 - 65535.000000 Resolution: 0 units/m Mode: absolute Current value: 40538.000000 $ xinput list-props 10 Device 'VirtualPS/2 VMware VMMouse': Device Enabled (121): 1 Coordinate Transformation Matrix (123): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (252): 0 Device Accel Constant Deceleration (253): 1.000000 Device Accel Adaptive Deceleration (254): 1.000000 Device Accel Velocity Scaling (255): 10.000000 Device Product ID (242): 2, 19 Device Node (243): "/dev/input/event3" Evdev Axis Inversion (256): 0, 0 Evdev Axis Calibration (257): <no items> Evdev Axes Swap (258): 0 Axis Labels (259): "Abs X" (274), "Abs Y" (275) Button Labels (260): "Button Left" (124), "Button Middle" (125), "Button Right" (126), "Button Wheel Up" (127), "Button Wheel Down" (128) Evdev Scrolling Distance (261): 0, 0, 0 Evdev Middle Button Emulation (262): 0 Evdev Middle Button Timeout (263): 50 Evdev Third Button Emulation (264): 0 Evdev Third Button Emulation Timeout (265): 1000 Evdev Third Button Emulation Button (266): 3 Evdev Third Button Emulation Threshold (267): 20 Evdev Wheel Emulation (268): 0 Evdev Wheel Emulation Axes (269): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (270): 10 Evdev Wheel Emulation Timeout (271): 200 Evdev Wheel Emulation Button (272): 4 Evdev Drag Lock Buttons (273): 0 Reverting commit 29dd395 locally solves the problem (tested with gedit)
Oh, wow... why does the vmware mouse report abs axes? I guess because it's easier to proxy from individual MotionNotify events. From the info you provide, that's basically indistinguishable from a legit single-touch screen. I guess the path forward is adding more device name checks, disconcerting though...
It's actually providing multiple devices (I really only have one mouse :D), the other one is reporting relative axes... $ xinput list 9 VirtualPS/2 VMware VMMouse id=9 [slave pointer (2)] Reporting 5 classes: Class originated from: 9. Type: XIButtonClass Buttons supported: 7 Button labels: "Button Left" "Button Unknown" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" Button state: Class originated from: 9. Type: XIValuatorClass Detail for Valuator 0: Label: Rel X Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 9. Type: XIValuatorClass Detail for Valuator 1: Label: Rel Y Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 9. Type: XIValuatorClass Detail for Valuator 2: Label: Rel Vert Wheel Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 9. Type: XIScrollClass Scroll info for Valuator 2 type: 1 (vertical) increment: -1.000000 flags: 0x2 ( preferred ) $ xinput list-props 9 Device 'VirtualPS/2 VMware VMMouse': Device Enabled (121): 1 Coordinate Transformation Matrix (123): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (252): 0 Device Accel Constant Deceleration (253): 1.000000 Device Accel Adaptive Deceleration (254): 1.000000 Device Accel Velocity Scaling (255): 10.000000 Device Product ID (242): 2, 19 Device Node (243): "/dev/input/event4" Evdev Axis Inversion (256): 0, 0 Evdev Axes Swap (258): 0 Axis Labels (259): "Rel X" (131), "Rel Y" (132), "Rel Vert Wheel" (251) Button Labels (260): "Button Left" (124), "Button Unknown" (245), "Button Right" (126), "Button Wheel Up" (127), "Button Wheel Down" (128), "Button Horiz Wheel Left" (129), "Button Horiz Wheel Right" (130) Evdev Scrolling Distance (261): 1, 1, 1 Evdev Middle Button Emulation (262): 0 Evdev Middle Button Timeout (263): 50 Evdev Third Button Emulation (264): 0 Evdev Third Button Emulation Timeout (265): 1000 Evdev Third Button Emulation Button (266): 3 Evdev Third Button Emulation Threshold (267): 20 Evdev Wheel Emulation (268): 0 Evdev Wheel Emulation Axes (269): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (270): 10 Evdev Wheel Emulation Timeout (271): 200 Evdev Wheel Emulation Button (272): 4 Evdev Drag Lock Buttons (273): 0 You could also add an exception for VMware (aka we know that they are lying...)
(In reply to Jonas Hahnfeld from comment #9) > You could also add an exception for VMware (aka we know that they are > lying...) That might work in the mean time, I would have to hope they don't add touch support proxying though :). I'm attaching a patch that checks for "mouse" in the device name, it should be safe to assume no touchscreen is going to have that...
Created attachment 315419 [details] [review] x11: Do not misdetect mice with abs axes as touchscreens VMWare seems to create mouse devices with abs axes which confuses our detection of single-touch touchscreens. Those have though a name we can match on ("VirtualPS/2 VMware VMMouse"), it should be pretty safe to assume that no real touchscreens have "mouse" in their name...
Review of attachment 315419 [details] [review]: This patch seems to work and solves my problem :-)
Attachment 315419 [details] pushed as b32c7c3 - x11: Do not misdetect mice with abs axes as touchscreens
Will this get included in 3.18 point releases? It wasn't merged for 3.18.5...
I apparently broke xwayland too... reopening and attaching another patch.
Created attachment 315756 [details] [review] x11: Add "pointer" to the is-not-a-touchscreen device name checks Commit 1266d15c4 also broke Xwayland, as it does the same trick than VMWare pointers. Let's extend the heuristic to check for "pointer" in the device name, what can possibly go wrong...
Review of attachment 315756 [details] [review]: alright then...down the slippery slope we go
Attachment 315756 [details] pushed as c5b7cd9 - x11: Add "pointer" to the is-not-a-touchscreen device name checks