GNOME Bugzilla – Bug 142536
Wacom pointer offset when using TopY other than 0
Last modified: 2011-02-04 16:10:27 UTC
Ratio of my Wacom and monitor don't match that well. Therefore I tried restricting the TopY with "xsetwacom set stylus TopY 7296". Works fine, except on GIMP image windows. Arrow and tool indicator icon are drawn where the pointer is supposed to be. But the brush appears some centimeters above it. The distances changes from bottom to top, becoming smaller. It seems the brush still moves like with unrestricted TopY, since the distortion is the same (checked by tracing a pencil sketch).
I might be wrong but I think that this should be completely transparent to the application. The problem would thus be either in the driver, the X server or at the GDK level. Should probably be reassigned to GTK+.
It works like it's supposed to on my whole desktop, Nautilus, Epiphany, Inkscape, whatever. So how could it be a problem of the driver, X server or GDK? And GIMP is the only app with special tablett support (I know of for Linux), what might have something to do with this problem.
Somebody pointed me to the "KeepShape" Option. It works fine, even in the GIMP. So there's still a bug, but nobody needs to trigger it.
It could very well be a bug in the driver or GDK since none of your other apps use the XInput coordinates, they only get the core pointer coordinates that are created to make the tablet usable as a standard mouse pointer device. Reassigning to GTK+.
This needs to be debugged by someone with a tablet.
I've looked into this a bit. It is mostly caused by bugs/limitations in the Wacom input driver for the X server, but there is a small issue in GDK as well. This is further complicated by the fact that the Wacom driver that is included in for example XOrg 6.8.2 is an old version while the linuxwacom.sf.net project has the most recent driver. I believe some distos ship the linuxwacom driver instead of the one that is bundled with XOrg and some do not. The following issues exist: 1. Running xsetwacom does not change the min/max values that XInput reports for the device, which can be verified with xidump (from the linuxwacom project). It works much better to specify the values in xorg.conf. This is a driver limitation. 2. The newest linuxwacom driver (but not the one included in XOrg 6.8.2) does not correctly handle TopX/TopY w.r.t. the axes ranges. If you specify TopY=1000 and BottomY=3000, it sets the min value to 0 and the max value to 2000 but the actual values reported are in the range 1000-3000. This can also be verified with xidump. 3. GDK does not completely take into account the min values for the X and Y axes when translating coordinates. The following linuxwacom bug report is about issue 1 and 2, and has a link to a patch that among other things appears to fix the issues. (It worked when I tested on my system but needs some work for devices in Relative mode) http://sourceforge.net/tracker/index.php?func=detail&aid=1375996&group_id=69596&atid=525124 I'll attach a possible patch for issue 3.
Created attachment 59736 [details] [review] Handle min values for X and Y axes in gdkinput-x11.c Here's a patch for gtk-2-8 that appears to fix the handling of the X and Y axes min values (issue 3 in the previous comment).
*** Bug 331171 has been marked as a duplicate of this bug. ***
I'm not in a position to test this, but it looks reasonable to me. If you have tested it, feel free to commit.
Using Gentoo with linuxwacom 0.7.2 and suffering these issues - Relative mode cursor (i.e. the mouse) works fine. Stylus and Eraser (the pen) are position sensitive and fail though. Do I apply the patch supplied to GTK+ (currently using 2.8.12) then recompile gimp and gimpshop? If I xidump stylus or eraser the results are: MINIMUM x-axis y-axis pressure x-tilt y-tilt wheel data: +10700 +09100 +00000 -00064 -00064 +00000 MAXIMUM x-axis y-axis pressure x-tilt y-tilt wheel data: +02000 +01500 +01023 +00063 +00063 +00000 THE OTHER STUFF x-axis y-axis pressure x-tilt y-tilt wheel min: +00000 +00000 +00000 -00064 -00064 +00000 max: +04700 +02600 +01023 +00063 +00063 +01023 res: +02540 +02540 +00001 +00001 +00001 +00001 My observations are that the stylus/eraser shouldn't be picking up a wheel (a pen with a wheel?!?) and that the min/max reported values a) don't correspond to the actual device min/max and b) don't correspond to the overriden settings in the xorg.conf. Know this is what Robert Ogren said but these are the results for resizing a 12700,10600 pad to a 2000-10700,1500-9100 incase it helps.
Would it be worth opening up a GIMP wishlist item asking for a co-ordinate override in the GIMP so that settings can be overrided on an application specific basis, thus neatly side stepping this issue until the harder fixes are made?
> Do I apply the patch supplied to GTK+ (currently using 2.8.12) then > recompile gimp and gimpshop? The GTK+ patch won't solve your problems by itself - if the min/max values reported by xidump are wrong then GTK+ will translate the coordinates wrongly even with the patch. To fix the problem you also need to patch linuxwacom. You might try the patch that is in the linuxwacom bug report I linked to in comment #6. When I tested, I removed the parts of that patch that dealt with rotation, but it might be easier to try the whole patch. Btw, normally there's no need to rebuild GIMP after rebuilding GTK+ - it is linked dynamically. > Would it be worth opening up a GIMP wishlist item asking for a > co-ordinate override in the GIMP so that settings can be overrided > on an application specific basis, thus neatly side stepping this > issue until the harder fixes are made? It is GTK+ that handles the coordinate translation so I don't think it is possible to work around in GIMP in a sane way. The workaround would need to be put in GTK+. However, it is probably not more work to help get the linuxwacom driver fixed than to implement a workaround. Btw, I just sent a question to the linuxwacom-devel list to ask for the status of the bug report.
Thank you - making some ebuilds for Gentoo with the patches in - your right - no need to recompile GIMP/GIMPshop.
Updated wacom patch to 0.7.2 on http://www.metalshark.co.uk/linuxwacom-0.7.2-rotate.patch
Anyone using Gentoo can find the overlays (with latest patchsets for gtk+-2.8.12 and Modular X on linuxwacom-0.7.2) on http://www.metalshark.co.uk/gtk+.tar.bz2 and http://www.metalshark.co.uk/linuxwacom.tar.bz2. All working fine now - thanks.
Gentoo ebuild for gtk-2.8.13 is now on the same location (http://www.metalshark.co.uk/gtk+.tar.bz2) - will this patch be added to the gtk package anytime soon?
Matthias: I think the patch can be committed as it has been tested both by me and by Beech Horn, and because the same solution was independently suggested by Denis Auroux in bug #324562. I would suggest something like this in the ChangeLog: * gdk/x11/gdkinput-x11 (gdk_input_translate_coordinates): Adjust the handling of min values for the x and y axes of extended input devices (#324562, #142536, Denis Auroux and Robert Ögren) I actually don't have write access, didn't get around to asking for it before "real life" got in the way. Matthias, could you please commit the patch if you think it's acceptable?
Sure. Thanks, Robert.
2006-03-04 Matthias Clasen <mclasen@redhat.com> * gdk/x11/gdkinput-x11 (gdk_input_translate_coordinates): Adjust the handling of min values for the x and y axes of extended input devices (#324562, #142536, Denis Auroux and Robert Ögren)
When clicking dragging inside a window using a pressure sensitive tool, if you roll over a GTK scroll bar the program closes (well GIMP 2.3.8) - is it worth opening a new bug for 2.3.8 - or is it a regression of this one? Only just came across the problem - have not discovered an issue for over two weeks of daily usage now.
Is this a new problem, ie did my change cause it ? If so, please reopen this bug. Otherwise, file a new one.
Ok - as this is closed I was just asking - gonna have to give me a couple of days to fully test it (failures are quicker to find than successes) - will post back here if the patch causes it (or not) - if it doesn't it'll be on a 2.3.8 GIMP bug.
Sorry for that it was just a bleeding edge issue - consider your patch stable - was quicker to find than I thought.
*** Bug 324562 has been marked as a duplicate of this bug. ***