GNOME Bugzilla – Bug 602733
Extended Input with Xinerama
Last modified: 2018-04-15 00:36:09 UTC
Created attachment 148317 [details] [review] replace screen_get_width with gdk_screen_get_monitor_geometry If a Desktop spans across two or more screens, XInput in screen mode maps to the entire desktop instead of the current screen. If for example, a screen of two 1680x1050 displays for a complete desktop of 3360x1050 are enabled, the xinput in gimp or inkscape in screen mode (where pressure sensibility is active) still behaves as if the tablet weren't restricted to only a single screen, even though the normal cursor knows better and stays at the same screen. The solution for it is to query the current screen's size and use this information instead of the entire size (gotten by gdk_screen_get_width/height)
This will have to be redone against the xi2 branch which we are going to merge sometime soon. But I am dubious about the claims here. [...] still behaves as if the tablet weren't restricted to only a single screen, even though the normal cursor knows better and stays at the same screen. What is restricting the 'normal cursor' to a single screen here ? And is the 'normal cursor' the core pointer, or the tablet ? Finally, is your setup really two screens, or is it to monitors that form a single screen ?
Created attachment 148495 [details] [review] corrected patch for tablet on multi-monitor environment
for some reason, the explanation for the above patch and the response to @mclasen's inquiry is not there anymore, so I'll try to sum up: The normal mouse cursor (as displayed by X) is still visible at the correct position, but the brush outline (e.g. in The GIMP) is at another position, i.e. scaled to the entire width of the screen instead of the current screen. So, b/c the entire screen is twice as wide as the current screen (in this setup), but at the same height, the position of the brush outline is at (2*x,1*y). Which is not what is expected. Restricting the cursor to a single screen is an option in the Wacom Tablet driver (the other possibilities are map the tablet to the entire desktop with or without keeping the aspect ratio, which in both cases loses resolution, either in one or both directions). My setup is one big xineramascreen consisting of two physical monitors. Querying the xineramainformation for the DISPLAY (:0.0) delivers two Xineramascreens with 1680x1050 each. So, it's not two separate servers or something like that.
In the current release 2.90 the issue still stands. Installing GTK directly from source I cannot work with GTK applications in screen modes on a xinerama setup spread over two or more displays. Adding the patch from comment 2 fixes the issue again.
the xi2 branch has not been merged yet...
The xi2 branch has been merged and is part of GTK 3. Is this still an issue with GTK 3 ?
Did not yet test applications with GTK 3 (Inkscape & Gimp), as the wacom driver still makes problems. Will try to do ASAP.
Resolving as OBSOLETE as per comment #6. Please reopen if this is still an issue.
I observed the same issues that Alex reported, but I have a different proposed resolution. The source issue is that the "screen" when running Xinerama is actually the entire virtual screen. Therefore, mapping a device that is a monitor itself (such as Alex's tablet, my Wacom Cintiq, or any Tablet PC) to this virtual "screen" does not make much sense. There are workarounds out there, such as setting the reported area of your tablet such that it ends up matching your current multi-screen layout, but those break every time you add or remove a monitor. Also, it is nonsense to make an input driver know about the current Xinerama configuration for unrelated displays. see http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Tablet_Set_Up#Dual_and_Multi-Monitor_Set_Up GDK should make use of the fact that GTK already knows about the concepts of monitors, like Alex proposed. But you cannot just make his change, because it breaks any other present devices that are not bound to the monitor, such as the core mouse cursor. If you try to use mouse and pen at the same time in gimp, you will see only one will be correct. Instead, I propose to add a new mapping mode MODE_MONITOR, which maps the device to the current monitor, not the entire virtual screen. I am attaching a patch that implements this. I tested with the mouse (set to SCREEN) and Cintiq pen (set to MONITOR) in an unmodified gimp 2.6.12 and they both work exactly as expected. I confirmed by inspection of the latest code in GTK 3 that the same exact scaling is still used in MODE_SCREEN. Could you therefore re-open this issue, please?
Created attachment 210591 [details] [review] add support for MODE_MONITOR to extended input device
Update: This patch is for GTK 2.24.7, because that is what I am using on Fedora 15. I could build an environment for 3.x master, if you need these changes for there. I also verified that this does the right thing for Inkscape. Since Inkscape uses GTKMM and GTKMM hard codes all the enum values (why not just use GType enumeration?) I had to first modify GTKMM, which took a while. But in the end, I was able to verify Inkscape 0.48.3.1 does the right thing and can configure "Monitor" for the pen/stylus/eraser, and configure "Screen" for the mouse and core pointer devices, because the latter DO in fact map to the entire virtual screen.
as per suggestion of Ammo Goettsch, I reopen the bug as to get things talked about again. Currently, my system isn't able to get this compiled, as I have major issues with my (somewhat outdated) GTK (and opensuse) installation.
I've ported Ammo's patch to the GTK master branch (current tip: 3.7.0-6-g41f2903). The port was done fairly mechanically; I don't have enough knowledge of GTK to know if there are additional bits that that have been added since 2.24.7 that need changing as well. While the code compiles, I have not been able to test it as yet. My development system is having trouble running in Xinerama mode with the radeon driver.
Created attachment 227319 [details] [review] Introduce MODE_MONITOR for extended input devices Update from Ammo Goettsch's 2012-03-25 patch.
Note so this does not get lost: The patch I submitted and which Jason then ported is missing the changes to gtk/gtkinputdialog.c which adds the MODE_MONITOR to the combo box. As a result, you cannot select "Monitor" mode in gimp GUI. You can change the mode to "monitor" in .gimp-x.y/devicerc for testing, though. The missing code looks similar to this: 257a258,264 > menuitem = gtk_menu_item_new_with_label(_("Monitor")); > gtk_menu_shell_append (GTK_MENU_SHELL (mapping_menu), menuitem); > gtk_widget_show (menuitem); > g_signal_connect (menuitem, "activate", > G_CALLBACK (gtk_input_dialog_set_mapping_mode), > GINT_TO_POINTER (GDK_MODE_MONITOR)); > I still have no development environment for GTK3.x so I cannot develop the patch.
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.
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