GNOME Bugzilla – Bug 168884
Xinerama issue : incorrect behaviour of drawing tools on the second head.
Last modified: 2014-03-28 13:47:51 UTC
Please describe the problem: I have a xinerama system setup like this : ________________________________ | | | | | | | | | | 1 | 2 | | | | |_____________| | | | | | |__________________| Head 1 : 1024x768 (Laptop monitor) Head 2 : 1280x1024 (external LCD) When using a drawing tool like the smudge one, or the pencil one on the image, on the second head, instead of getting dots, or curves like I want, I get a line starting from far on the left to my cursor : ________________________________ | | | | | | | | | | 1 |_______________. | | | line |\ | |_____________| c.| | | | | |__________________| It acts just like I drew a left->right line to stop where the cursor actually was. What's strange is that the line is exactly 1024px long, the Hres of head 1. I guess it has to be a problem with gimp/gtk reading the coordinates value of the cursor. I tried to run xev -id <image window id> but couldn't get anything special. The coordinates serie is just continous when switching from a monitor to the other. Steps to reproduce: 1. open an image on screen 2 2. try drawing something with the pen, the pencil, the smudge too, etc Actual results: A 1024px long line is drawn from the left side of the window to the actual position of the mouse cursor. Expected results: The drawing should just be drawn the way the cursor moves. Does this happen every time? Not at every click, but something like 20% of the time. Other information: We talked a while on IRC, and we didn't find any obvious solutions. It seems it's not a mouse problem, not a xinerama problem. Nothing strange happens on monitor 1. My system is updated to the latest debian sid pkg (libgtk2.0-0 2.6.2-3). Here is a screenshot of the problem : http://mymom.is-a-geek.org/~nerf/fat/sshot/shot-gimp.png
I am pretty sure that this is not a GIMP bug. Simply because GIMP should not have to care about Xinerama except for a few things like placement of popup menus and windows. Xinerama happens completely in the X server, the application only sees a large screen. If GIMP is misbehaving on a Xinerama setup, that's a bug in the X server then. I suggest that this report is being closed as NOTGNOME.
Might be a xserver problem, however, this bug is gimp only (oodraw, dia, sketch, xfig, sodipodi work just fine). I might restart X tomorrow and see what happens then.
This might be a duplicate of bug #66813. It seems that gdk_device_get_history() does not compensate for the offset of the second xinerama screen.
If the bug is really in gdk_device_get_history(), we can compensate for that until GTK+ is fixed. Added a comment to bug #66813, asking the GTK+ folks to verify whether this one is a duplicate. Setting milestone to 2.2 because the workaround would be very local and the code has not changed in HEAD.
Mitch, since it doesn't seem like GTK+ will have this fixed anytime soon, do you think we should attempt a fix in gimp 2.2 ?
How would we find out if GTK+ has been fixed? I suggest we close this as duplicate of bug #66813. Someone should then try to fix the problem in GTK+.
I experience something similar. My xinerama setup is two 1920x1200 monitors. Same res. When painting on head 2, sometimes the brush shoots towards the other monitor and back. This doesn't seem to be a GIMP bug, as I get similar behavior with Inkscape's tools. http://jimmac.musichall.cz/demos/xinerama-shooting.avi http://jimmac.musichall.cz/demos/inkscape-xinerama-shooting.avi
Ok, seems it's not a duplicate then, and doesn't look like something an application can work around. Reassigning to GTK+.
I failed to mention that while I am using a wacom and have the device configured, it's not attached and I am using a normal mouse. My xorg.conf: http://jimmac.musichall.cz/stuff/xorg.conf
Is this bug still relevant ? A lot has changed since 2006...
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!