After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757358 - single touch devices are not detected as touch devices
single touch devices are not detected as touch devices
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GdkDevice
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2015-10-30 12:11 UTC by Olivier Sessink
Modified: 2015-11-17 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN (2.09 KB, patch)
2015-10-30 13:18 UTC, Carlos Garnacho
none Details | Review
x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN (2.24 KB, patch)
2015-10-30 13:41 UTC, Carlos Garnacho
committed Details | Review
x11: Do not misdetect mice with abs axes as touchscreens (1.29 KB, patch)
2015-11-13 16:24 UTC, Carlos Garnacho
committed Details | Review
x11: Add "pointer" to the is-not-a-touchscreen device name checks (1.09 KB, patch)
2015-11-17 14:58 UTC, Carlos Garnacho
committed Details | Review

Description Olivier Sessink 2015-10-30 12:11:22 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)
Comment 1 Carlos Garnacho 2015-10-30 13:18:08 UTC
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.
Comment 2 Emmanuele Bassi (:ebassi) 2015-10-30 13:22:52 UTC
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.
Comment 3 Carlos Garnacho 2015-10-30 13:40:54 UTC
(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.
Comment 4 Carlos Garnacho 2015-10-30 13:41:16 UTC
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.
Comment 5 Matthias Clasen 2015-10-30 14:33:03 UTC
Review of attachment 314484 [details] [review]:

sure
Comment 6 Matthias Clasen 2015-11-03 12:13:58 UTC
Attachment 314484 [details] pushed as 29dd395 - x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN
Comment 7 Jonas Hahnfeld 2015-11-13 10:44:10 UTC
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)
Comment 8 Carlos Garnacho 2015-11-13 11:08:30 UTC
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...
Comment 9 Jonas Hahnfeld 2015-11-13 11:52:36 UTC
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...)
Comment 10 Carlos Garnacho 2015-11-13 16:24:05 UTC
(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...
Comment 11 Carlos Garnacho 2015-11-13 16:24:46 UTC
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...
Comment 12 Jonas Hahnfeld 2015-11-14 17:12:00 UTC
Review of attachment 315419 [details] [review]:

This patch seems to work and solves my problem :-)
Comment 13 Matthias Clasen 2015-11-15 04:46:31 UTC
Attachment 315419 [details] pushed as b32c7c3 - x11: Do not misdetect mice with abs axes as touchscreens
Comment 14 Jonas Hahnfeld 2015-11-17 09:06:02 UTC
Will this get included in 3.18 point releases? It wasn't merged for 3.18.5...
Comment 15 Carlos Garnacho 2015-11-17 14:57:45 UTC
I apparently broke xwayland too... reopening and attaching another patch.
Comment 16 Carlos Garnacho 2015-11-17 14:58:38 UTC
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...
Comment 17 Matthias Clasen 2015-11-17 15:00:55 UTC
Review of attachment 315756 [details] [review]:

alright then...down the slippery slope we go
Comment 18 Carlos Garnacho 2015-11-17 15:24:23 UTC
Attachment 315756 [details] pushed as c5b7cd9 - x11: Add "pointer" to the is-not-a-touchscreen device name checks