This can't be fixed without linking to the Xinerama extension, and
that is being put of for 2.2 as:

 - Xinerama still isn't properly standardized (a new standard
   is being worked on, which is quite different in detail)
 - There is interaction with separate screen multihead support, which
   is being added for 2.2.

Is this still an issue ?
Xinerama support has been in GTK+ for some years now.

Don't remember anybody fixing it. It needs code written to fix.

Would you have a look at GIMP bug #168884 and tell us if it's the
same problem?

I have a very basic xinerama setup (2 identical screens side by side)
and observe the same behavior on all versions of Gimp (1.2, 2.2,2.3):
Cursor positions and everything else are normal, but drawing or other
actions on the tablet are shifted ~300 pixels to the left.

actually, the effective coordinates are:
- left-shifted on the right screen: real position - distance from the right edge
- right-shifted on the left screen: real position + distance from the left edge

Somebody with a multihead + tablet setup will have to write a patch
for this. I have neither multihead nor a tablet...

After looking into the issue a little deeper, I guess this
is probably a duplicate of
Bug 324562 – XInput events are at incorrect xy-coordinates
(which is still open, but has been fixed in gtk+ 2.8.14)

I could verify that the problem is gone in gtk+ 2.8.16

with gtk+ 2.8.16, gimp obviously can't distinguish between
the different tablet devices (pen,eraser,mouse) and the mouse
anymore (maybe a collateral dammage of the fix for this bug?)

Sorry, I've been a little too fast with my success report:
I had overlooked that xinput support has to be explicitly
requested.

Bug 324562 has nothing to do with this issue and the problem
is still there in 2.8.16. :-(

Created attachment 66366 [details] [review]
Fix for GDK_MODE_SCREEN xinput devices

In general the problem seems to be, that the xinput-coordinates
are bound to the current monitor, while xinerama-coordinates are
referring to the whole logical screen.
This patch should fix the problem for input devices set to screen
mode (I didn't touch window mode because I have never used it and
am not so sure how it should behave.)
There is at least one pathological case left when the current window
stretches over several monitors, but there probably isn't any good
solution for this, because it obviously is not possible to get the
pointer across the monitor boundary with an xinput device (if anybody
knows how to do this trick, let me know :)

Created attachment 66416 [details] [review]
Fix for GDK_MODE_SCREEN xinput devices (slightly enhanced)

Here's the same thing in a slightly enhanced version that always referrs
to the geometry of the screen that currently contains the core pointer.
This way windows that span across several monitors mostly work (there
still is a little glitch when the monitor boundary is crossed).

There probably can't be a solution that works under all circumstances
and for all devices: I just tried a newer wacom driver and found out
that there now is a mode where the input coordinates are mapped to the
whole logical screen (which would require different scaling). I don't
know how other input devices might handle this. This patch assumes that
the device is either in relative mode or that the corresponding
core pointer events are confined to the current monitor...

Could somebody check please if bug #168884 is a duplicate of this
one? I don't have xinerame so I don't even see the problem here.

(In reply to comment #13)
> Could somebody check please if bug #168884 is a duplicate of this

As far as I understand, bug #168884 occurs with a regular mouse, while
this issue is an error in translating xinput coordinates, so I think
it's 2 different problems.

It would be really nice if we could avoid the get_pointer call. What is the relevance of the core pointer position for this, anyway. Can't you have the core pointer on one monitor, and the tablet on the other ?

(In reply to comment #15)
> It would be really nice if we could avoid the get_pointer call. What is the
> relevance of the core pointer position for this, anyway. Can't you have the
> core pointer on one monitor, and the tablet on the other ?

At least as far as I can tell, pretty much everybody who uses a tablet has
set it up to generate core events. Gimp in GDK_MODE_WINDOW would be pretty
much the only occasion where a different setup could make sense (but it would
be even harder to get that right).

The call to get_pointer and the other stuff is the only way I could figure out
to get the current monitor and the geometry of this monitor because that's
the coordinate system the xinput coordinates are based on.

Unfortunately, there probably is no way to fix this issue for all possible
configurations without mutual consent between the wacom driver, xinput and
GDK, which coordinate system to use on which occasion...

Hi, at the blender institute we are using gimp on ubuntu gutsy with blender.

The project site is here if anyones interested.
http://peach.blender.org/

We have the same problem.
(tested xinerama and twinview) with a wacom tablet configured to use XInput with The Gimp 2.4.

Our problem is that even when mapped to 1 screen, the gimp gets coords as if the stylus was mapped to 2 screens - the cursor is often outside the view.

It seems this is definitely a GTK bug, since Krita with kde4 beta does not have this problem.

What is the state of the patch provided? would if help if we review? or are there some other issues with it?

If there is any development involved we could try to discover a solution ourselves since one of the developers here is familiar with the gimp's code and could probably try some gtk coding too... failing that I can look into it too ;)

correction, krita does not work. this makes me wonder if the bug is GTK.
the qt/kde app pencil works http://www.les-stooges.org/pascal/pencil/ but that migh deal with xinput differently.

Update, we managed to get the wacom tablets working perfectly with xinerama.
I need to discuss with one of the other guys, but by changing a setting in xorg.conf its possible to have it working where dual screen coords are not used in the gimp for single screen mode.

Will post an update later with teh settings to change and our configuration.

This is the configuration file used to get the tablet working perfectly on one screen, using nvidia binary drivers.
################

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "stylus" "SendCoreEvents"
    InputDevice    "eraser" "SendCoreEvents"
    InputDevice    "pad" "SendCoreEvents"
EndSection

Section "Files"
    RgbPath         "/usr/X11R6/lib/X11/rgb"
EndSection

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection

Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "InputDevice"
  Driver        "wacom"
  Identifier    "stylus"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "stylus"
  Option        "USB"           "on"                  # USB ONLY
  Option 	"Twinview" 	"horizontal"
  Option	"ScreenNo"	"0"
EndSection

Section "InputDevice"
  Driver        "wacom"
  Identifier    "eraser"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "eraser"
  Option        "USB"           "on"                  # USB ONLY
  Option 	"Twinview" 	"horizontal"
  Option	"ScreenNo"	"0"
EndSection

Section "InputDevice"
  Driver        "wacom"
  Identifier    "cursor"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "cursor"
  Option        "USB"           "on"                  # USB ONLY
  Option 	"Twinview" 	"horizontal"
  Option	"ScreenNo"	"0"
EndSection

# This section is for Intuos3, Cintiq 21UX, Graphire4, or Bamboo
Section "InputDevice"
  Driver        "wacom"
  Identifier    "pad"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "pad"
  Option        "USB"           "on"                  # USB ONLY
  Option 	"Twinview" 	"horizontal"
  Option	"ScreenNo"	"0"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "EIZO S2000"
    HorizSync       31.0 - 76.0
    VertRefresh     59.0 - 61.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "EIZO S2000"
    HorizSync       31.0 - 76.0
    VertRefresh     59.0 - 61.0
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
EndSection

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro FX 1700"
EndSection

Section "Device"
    Identifier     "Videocard1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro FX 1700"
    BusID          "PCI:7:0:0"
    Screen          1
EndSection

Section "Screen"

# Removed Option "TwinView" "0"
# Removed Option "metamodes" "DFP-1: nvidia-auto-select +0+0"
# Removed Option "metamodes" "DFP-0: nvidia-auto-select +1920+0, DFP-1: nvidia-auto-select +0+0"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "1"
    Option         "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-1: nvidia-auto-select +1600+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Videocard1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "DFP-0: nvidia-auto-select +0+0"
EndSection

(In reply to comment #20)
> Update, we managed to get the wacom tablets working perfectly with xinerama.
[...]
> This is the configuration file used to get the tablet working perfectly on one
> screen, using nvidia binary drivers.
[...]
>     Option         "TwinView" "1"

The problem in question doesn't arise in your configuration, because it is
not using Xinerama: The "TwinView" setup in Nvidia's proprietary driver
merges the 2 monitors to 1 framebuffer.
The X server (as most other programs) just sees one particularly wide screen,
so the coordinate system that is beeing used always stretches over both monitors.
(which actually even as far as the tablet is concerned isn't much progress,
because it means. that the input from a tablet with an aspect ration of 4:3
is mapped to an area of 8:3 in a typical setup).

This patch works well for me for me on three screen xinerama with different screen sizes.

But gtk+ still not reacts to chenging tablet's area size by xsetwacom set stylus TopY 1005. But this is another bug.

(In reply to comment #22)

> This patch works well for me for me on three screen xinerama with different
> screen sizes.

This patch works great for me and finally I can use my Bamboo Fun in Gimp without any limitations. I tried on Ubuntu 8.04 (applied patch to gtk+ 2.12.9 source package). Hope the patch will make it into one of next versions. I haven't seen the code in the latest 2.14 source.

Hi guys. I'm still having this problem and for me is a major issue, as in "blocking".

Is this going to be merged soon in the 2.14 tree? I'm currently using 2.14.7. Is there anything I'm missing?

2001 to 2009 is eight years.

The patch doesn't work now because input_window->window has been removed from the struct.

Perhaps a GTK / GDK developer can help out here?  What is a suitable replacement for the variable?

Thanks guys.  It has a pretty serious impact on any production workflow as most people in those environments (see Blender developer posting above) are running dual head with dedicated video cards.

Upgraded GTK+ affected version per comment #24 , Can someone confirm this in a newer version?

Why not just use pointer origin provided by X server? Why gtk shuold allow drow somewhere else but not where X pointer is?

@Javier Appears the same.

I created a new patch that works in https://bugzilla.gnome.org/show_bug.cgi?id=634977

Move input bugs to GdkDevice

I don't think this bug is no longer useful to keep open - we are now using xi2 and xrandr for a long time.