GNOME Bugzilla – Bug 703610
[GTK 3 series] Problems with UC-Logic WA60 tablet
Last modified: 2015-03-02 19:01:26 UTC
The behavior of the UC-Logic WA60 Tablet is very strange... the stroke is irregular and discontinued. In the Mypaint (git master version) that is being ported to gtk 3... the problem is evident. I've many tests on mypaint and gtk. Martin Reinold, main Mypaint developer write me that is useful open a bug here. The initial and main considerations about this problem you can find in: https://gna.org/bugs/?20883 https://bugzilla.gnome.org/show_bug.cgi?id=702392 [perhaps] I've tested with different machines (ubuntu and ubuntu gnome) and different gtk-3 releases and the behavior is the same: On ubuntu gnome 12.10 Version: 3.6.2-0ubuntu1~ubuntu12.10.2 On ubuntu gnome 13.04 Version: 3.6.4-0ubuntu8 On ubuntu gnome 13.10 alpha 1 Version: 3.8.2-0ubuntu7 I've made the testinput test https://www.youtube.com/watch?v=L_Iqs-bGWaI The tutorial for my tests is here: http://wiki.mypaint.info/Development/Debugging_Tablet_Issues#Testing_GTK3_tablet_support
Created attachment 252466 [details] pressure-snake.c Jose: I can't quite make out what's happening in your video. Are you able to post the text output? I suspect that on this input device, the input pressure drops to zero at random. I'm fairly certain that this has nothing to do with bug 702392 because you report it for GTK+ 3.6, which was released before the motion compression patch went in. I've adapted maxy's motion-snake.c to show pressure (thin+red=low, wide+green=high). Jose: please test with the instructions at the head of the attached file, and post a screencap of what you see when you run it with your tablet. Try and post a long swirling stroke with constant medium pressures. Can the problem be reproduced? I would expect green strokes to drop to red "at random".
Jose: do you know what input driver Xorg is using for this tablet? Try $ tail -f /var/log/Xorg.*log and look for any "(II) Loading /usr/lib/xorg/modules/input/<something>.so" lines.
(In reply to comment #1) > Created an attachment (id=252466) [details] > pressure-snake.c > > Jose: I can't quite make out what's happening in your video. Are you able to > post the text output? I suspect that on this input device, the input pressure > drops to zero at random. > > I'm fairly certain that this has nothing to do with bug 702392 because you > report it for GTK+ 3.6, which was released before the motion compression patch > went in. > > I've adapted maxy's motion-snake.c to show pressure (thin+red=low, > wide+green=high). > Jose: please test with the instructions at the head of the attached file, and > post a screencap of what you see when you run it with your tablet. Try and post > a long swirling stroke with constant medium pressures. Can the problem be > reproduced? I would expect green strokes to drop to red "at random". I've the test with the pressure-snake.c and it seems that the pressure is going to zero in random way. I've made a short video about this test: http://www.youtube.com/watch?v=z6utH5FS3SE&feature=youtu.be
Created attachment 252476 [details] tail -f command output
Created attachment 258075 [details] Output of tail command on ubuntu-gnome 13.10
New tests on Ubuntu Gnome 13.10 The pressure is going still to zero on random way: http://www.youtube.com/watch?v=rE-ZetIQ5Q4&feature=youtu.be
Nikolai Kondrashov <spbnick@gmail.com> Hi Americo, Sorry for not answering for so long, I've had a lot happening recently. On 11/17/2013 04:03 AM, José Américo Gobbo wrote: > I've find a temporary solution to my problem with UC-LOGIC TWA60 - MONOPRICE > 10X6. I've used a .conf on /etc/X11/xorg.conf.d forcing the uc-logic works > as wacom tablet with xsetwacom. > the tip works fine for this tablet and resolves the strange behavior on > mypaint with gtk3. > Another question... is possible that problem is in the relation between > evdev and gtk3 and not exclusively of the gtk3? This is most likely due to the difference evdev and xf86-input-wacom reporting coordinates differently. The Wacom driver always reports *all* of the coordinates, the evdev driver only reports coordinates that have changed since the last report, which is correct WRT the protocol. This is what confuses GTK3, most likely. This was happening in the past to other software, certainly. I'd suggest mentioning this in the bugs you reported. Sincerely, Nick
bug 700110 is probably a duplicate of this. MyPaint has a workaround now, since I've been able to replicate this with Wacom hardware input processed through the evdev driver: https://github.com/mypaint/mypaint/issues/29 Differences between evdev and xf86-input-wacom reporting seem to be a bit of a red herring. All events we see have all axes present: it's just that with evdev the values for pressure and tilt are reported as 0 when the value has not changed since the previous event (or when the value goes over 1 for pressure and until it drops back, which is sort of the same thing).
> Differences between evdev and xf86-input-wacom reporting seem to be a bit > of a red herring. Ignore me there. The g_new0() in translate_axes() defined in https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-xi2.c?id=234fec1#n855 is probably responsible for this. Note that not every bit in valuators->mask might be set for every event, and we have good reasons to suspect that this is happening with evdev per comment 7 and comment 8. translate_axes() gets called when populating a button, motion, or touch event's axes field: https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-xi2.c?id=234fec1#n1411 so the resultant event gets zeros whenever the XI2 XIValuatorState struct omits an axis[1], and there's no way a Gtk application can even infer this has happened when presented with an event. Would it be possible to populate axes with better data than 0 for this case please? Either: A) Use the last reported value for this axis from the device (nice for app developers, but not necessarily correct in all cases) B) Populate missing axes with nan so that at least apps know about its absence (kinda unpleasant for app developers, but MyPaint gtk2 code has done this in the past; it's not insurmountable) [1] http://who-t.blogspot.co.uk/2009/07/xi2-recipes-part-4.html
Created attachment 298055 [details] Brief graph of stroke with 'increasing' pressure Created using Andrew's tool: https://gist.githubusercontent.com/achadwick/54e5b111e5ac908becf1/raw/6491865277c2ffec188c4d49303ccb9c6633ad2b/axischart.py and a Monoprice 12" aka UC-Logic PF1209 tablet. Graph is of a diagonal stroke from bottom left of window to upper right, with gradually increasing pressure. The Missing pressure values are very evident.
(In reply to Andrew Chadwick from comment #10) > Would it be possible to populate axes with better data than 0 for this case > please? Either: > > A) Use the last reported value for this axis from the device (nice > for app developers, but not necessarily correct in all cases) > I think this is the most workable approach, GDK knows as much as X tells after all. The only rough spot is detecting pressure actually going to 0, I guess we can just hack this on button release.
(In reply to Carlos Garnacho from comment #12) > > I think this is the most workable approach, GDK knows as much as X tells > after all. The only rough spot is detecting pressure actually going to 0, I > guess we can just hack this on button release. Zero is a perfectly legit pressure, and that's a pain. Is X *really* reporting zero for the axis, or is it just skipping it and leaving GDK to report zeroed memory? The test at https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-xi2.c?id=3ce3593#n947 could easily result in unexpected zeros (zeroed RAM == +0.0 in IEEE binary64 notation). If X really is reporting zero, you might be able to test (event->state & GDK_BUTTON[1..5]_MASK) elsewhere, but I've not tested that this even works. MyPaint's workaround uses button-down and button-up instead.
Possible related Xorg/evdev bug and discussion: https://bugs.freedesktop.org/show_bug.cgi?id=82181 though possibly it's just illustrative of what toolkit-level stuff has to deal with from this driver. This one may go quite deep, but if it can be worked around sensibly in GDK it should be so that apps don't have to.
"Button release" does not imply "zero pressure". At least for wacom devices there is a configurable (via xinput) click pressure threshold. For painting, pressure below the click threshold can be quite useful. With an external tablet, point-and-click is much more precise/comfortable when you always touch the surface slightly. If you have to hover just above the surface (to avoid clicking) your hand is unstable and the hardware tracking gets worse with distance, too.
(In reply to Andrew Chadwick from comment #13) > Is X *really* reporting zero for the axis, or is it just skipping it and > leaving GDK to report zeroed memory? > The test at > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-xi2. > c?id=3ce3593#n947 could easily result in unexpected zeros (zeroed RAM == > +0.0 in IEEE binary64 notation). Yup, this was the case in the end. It is then quite safe to keep the last axis values around, and just use these if a valuator is missing in the mask/array. I'm attaching a patch doing that.
Created attachment 298333 [details] [review] x11: Store last axes from device And use these for the missing axes if the valuator mask is incomplete. This used to work fine on tablets because the Wacom driver ensures all valuators are sent, which is not true if using the evdev device.
Attachment 298333 [details] pushed as 4cae9bd - x11: Store last axes from device
Thanks, Carlos! It may be some time before I can test this, so I've asked others to try it out and feed back here.