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 700110 - Most input from tablets using evdev driver is dropped.
Most input from tablets using evdev driver is dropped.
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Class: GdkDevice
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2013-05-11 02:36 UTC by David Gowers
Modified: 2018-04-15 00:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Log of 'testinput' console output (21.14 KB, application/octet-stream)
2013-05-11 02:36 UTC, David Gowers
Details
'testinput' screenshot clearly showing line breakage. (35.93 KB, image/png)
2013-05-11 02:37 UTC, David Gowers
Details
axischart.py (4.97 KB, text/plain)
2014-07-13 14:25 UTC, Andrew Chadwick
Details
axischart.png (9.42 KB, image/png)
2014-07-13 14:28 UTC, Andrew Chadwick
Details

Description David Gowers 2013-05-11 02:36:11 UTC
Created attachment 243825 [details]
Log of 'testinput' console output

The mouse pointer is always accurate to the stylus position on the tablet, but
the reporting of extended input information to GTK+3 applications frequently drops out (for durations ranging from 0.1 sec to 50 sec). When a report *is* given, it does correctly reflect the actual state of the tablet (pressure and position).

I first experienced this bug in MyPaint, after the recent migration to GTK+3. I ended up reverting to the GTK+2 version, in which all input is reliably reported.

After this, I tested GTK+3 itself using the 'tests/testinput' program. The output (both a screenshot, and the console output) is attached. You can see the massive line breakages clearly. I labeled the approximate points travelled between to clarify that if the reporting was working properly, you would see an approximate X, unbroken.


Further information:

Switching to the 'wacom' driver disables right and middle-clicking but makes reporting functional again. This is the reason I concluded this bug is related to interaction with the evdev driver.

Tablet: Monoprice 9x12 (a rebadged UCLogic -- lsusb reports it as "UC-Logic Technology Corp. Tablet PF1209"). This is the only pointing device attached to my system.
OS: Arch Linux x86_64
GTK+3: 3.9.0
xorg-server: 1.14.1
xf86-input-evdev: 2.8.0

"xinput list" output:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳                 9x12 Tablet             	id=9	[slave  pointer  (2)]
⎜   ↳                 9x12 Tablet             	id=10	[slave  pointer  (2)]
⎜   ↳                 9x12 Tablet             	id=11	[slave  pointer  (2)]
⎜   ↳ Acer IR  Receiver                       	id=12	[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)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ CHICONY HP Basic USB Keyboard           	id=8	[slave  keyboard (3)]

(#11 appears to be the device that input is reported from.)
Comment 1 David Gowers 2013-05-11 02:37:51 UTC
Created attachment 243826 [details]
'testinput' screenshot clearly showing line breakage.
Comment 2 Andrew Chadwick 2014-07-13 14:20:15 UTC
Confirmed here with Debian testing/unstable GTK/GDK 3.12.2, xserver-xorg-input-evdev 2.8.2, a Wacom tablet (via evdev), and stock Debian amd64 kernel 3.14.9.

There is more detail in the MyPaint bug report, https://github.com/mypaint/mypaint/issues/29 - initially I though it was only UC-Logic-based tablets showing the issue, but perhaps any device reporting via X11 and evdev could show the problem.

The symptoms are that the pressure and tilt axes tilt drop to zero when they haven't changed since the last event. I guess wheel too, but I don't have any device which exercises that.

For us, it clearly makes strokes discontinuous if left untreated. MyPaint now has a workaround for this, https://github.com/mypaint/mypaint/commit/c8a84143baefc5b58e8ef9dc33e632a909beaf53 , but apps *really* shouldn't have to deal with this nonsensical input from GDK (or evdev, or the X11 evdev driver...). Since it apparently works fine with GTK2 Gdk and not with GTK3 Gdk, presumably it's a regression?
Comment 3 Andrew Chadwick 2014-07-13 14:25:26 UTC
Created attachment 280588 [details]
axischart.py

Strip chart axis plotter, used for the screen grab in the github issue (I'll attach its output here too). Clearly demonstrates the nature of the problem.

Apologies for crappy code and the broken gtk2compat stuff. It's non-functional, probably because I fail at remembering the precise launch codes for getting extension events working with PyGTK. Just run it in GI+GTK3 mode by calling it without the option and you'll be fine.
Comment 4 Andrew Chadwick 2014-07-13 14:28:31 UTC
Created attachment 280589 [details]
axischart.png

Lines in the chart, from top to bottom, are X, Y, Pressure, XTilt and YTilt. No Wheel because I don't have that on my tablet.

Note the dropouts in the axes other than X and Y.
Comment 5 Andrew Chadwick 2014-07-16 11:42:13 UTC
Probably a duplicate of bug 703610.
Comment 6 Matthias Clasen 2018-02-10 04:57:12 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 7 Matthias Clasen 2018-04-15 00:03:33 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new