GNOME Bugzilla – Bug 721398
clipboard not working across screens
Last modified: 2015-09-19 00:25:40 UTC
on GTK+ 3.10.6 + c7c4b0c5fddb6b9d1e4c79c18f5b2a2c82e0bb77 I am unable to copy'n'paste from one screen to the other. This is a pretty serious regression as copy'n'paste is a core functionality of graphical environments. Both the old-style highlight-then-middle-button-paste is not working nor is even ctrl-c/ctrl-v style cut'n'paste. Even Copy/Paste from the menu of gtk applications is not working.
I can confirm this bug with Version 3.12.2 on Gentoo Linux amd64.
I can confirm this bug with GTK+ 3.14.6 on FreeBSD (amd64).
Created attachment 293554 [details] [review] Proposed fix based on gtk-3.14.6 source The bug seems to be in `_gdk_x11_display_screen_for_xrootwin`, which does not seems to be multi-screen aware. This diff fixes it by creating a new GdkScreen instance for the window's screen. The possible issue with this fix is that "GdkScreen*" created here is not being tracked (to be freed later). I'm not much familiar with the internals of GTK+, but if anyone has any ideas on how to properly fix it, I can further work on it. But for now, it has fixed the big annoyance for me. Thanks!
ATM the current fix results in following message, when pasting for second time to an application on a different screen: "Gdk-WARNING **: XID collision, trouble ahead" This is triggered by re-addition of root window of second screen to display's XID hashtable. I tried looking at using some GDK magic for a better fix, but it seems like GDK is explicitly hardcoded to assume only single screen in 3.10.[1] [1] https://git.gnome.org/browse/gtk+/commit/README.in?h=gtk-3-14&id=88d59448eab595f0f5461744c47b030d056561dc Sigh!
I think one has to understand the changelog entry in [1] in a way that one should open the second screen as fully fledged display within the GTK program. This would mean that the clipboard would then have to work across displays. No idea if this is possible, since the clipboard seems to be bound to the specific display.
Well, in my case, I only run single Xorg instance which offers two screens :0.0, :0.1, so single DISPLAY with shared CLIPBOARD.
Of course, I didn't want to imply that the setup whould be different (I run the same setup). The way I understand the commit message is that one should open the screens as different displays, something like: screen0 = gdk_display_open(":0.0"); screen1 = gdk_display_open(":0.1"); The problem is now that the clipboard is bound to a specific display, and by accessing the separate screens via separate display, copying from one display to another one becomes impossible with gtk3 >= 3.10. For some more insight see Bug #719314 [1]. Now to fix this bug one would somehow have to enable GtkClipboard to work across displays, which most likely would require the clipboard to track that the displays belong to the same X session, because otherwise a security risk is introduced. [1] https://bugzilla.gnome.org/show_bug.cgi?id=719314
*** Bug 752741 has been marked as a duplicate of this bug. ***
Sadly Xnest -scrns 2 segfaults the moment a client connects, nowadays. So there is no easy way to work on this - Xephyr doesn't support multiple screens.
Try Xnest with the -nocursor option. For me on Gentoo and on Debian stretch this avoids the segfault. There is of course also the option top set up a machine to run with two separate X screens on two monitors :)
*** Bug 755116 has been marked as a duplicate of this bug. ***