xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Version 12 (modified by Antoine Martin, 9 years ago) (diff)

add new ticket link



Clipboard support is an ongoing struggle. One common difficulty with Windows clients is that these platforms only have a single (*) clipboard whereas X11 has three (CLIPBOARD, PRIMARY and SECONDARY), and therefore we need to choose which one to exchange with. This can be changed at runtime via the tray menu. (see also #272) Another Windows-specific problem is to do with the way it pulls clipboard data as soon as we claim ownership of the selection (see workaround in r3051 + r3075) On OSX, I cannot find any good asynchronous clipboard API, the clipboard is simply not implemented there yet (see #11)

A more technical issue is to do with the way the clipboard hooks are implemented, using native C code (wimpiggy.gdk.gdk_atoms Cython code imported in xpra.platform.gdk_clipboard) and nested main loops.

Testing the clipboard

The easiest way to test the clipboard is to use xclip to set and verify the contents of each clipboard:

  • To set the "primary" clipboard contents to the string "_primary_":
    echo _primary_ | xclip -i -selection primary
  • To print the contents of the "primary" clipboard:
    xclip -o -selection primary

Note: on win32, you will need to change the clipboard currently in use to match the one you modify, this must be done before changing the value to ensure it is propagated.

Debugging: set XPRA_CLIPBOARD_DEBUG=1 before running to get clipboard debugging information.

Starting with v0.9.0 there is also a tool which can be used to diagnose clipboard behaviour:

  • GTK_Clipboard_Test.exe on win32
  • xpra/gtk_view_clipboard.py on posix

see #272 comment:5 for screenshots and help with that.

Useful Pointers

Here are some pointers:

And here is a good quote from it:

Clipboard sharing and network transparency: It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is possible, but such an implementation would be needlessly difficult and complex. The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard between a virtual machine and the desktop itself is painfully difficult to implement correctly (in case X11 is running on the host operating system).

Source code

  • xpra.platform.clipboard_base - the base class for clipboard implementations
  • xpra.platform.gdk_clipboard - the gdk clipboard implementation (which requires Cython to build the C parts that allow us to access X11 atoms). It also contains the TranslatedClipboardProtocolHelper which is used by Windows clients to translate the local clipboard to a particular X11 clipboard.

Related tickets

  • #41: when we support concurrent users on the same session, we currently give the clipboard to the first client - doing anything else will be quite tricky
  • #272 win32 multiple clipboards enhancement
  • #318 osx client-to-server clipboard support
  • #273 handle more clipboard formats
  • #274 advanced clipboard filtering
  • #275 handle clipboard large data transfers better
  • #276 limit clipboard direction
  • #313 speedup paste
  • #184 clipboard related bug, clipboard can fire at any time... so bugs may appear to come from somewhere else when in fact it is the clipboard that is the source of the problem - to keep in mind
  • #162 very hard to reproduce bug - relied on the list (and their order) of X11 atoms defined, as we tried to parse invalid values as X11 atoms
  • #176 32-bit vs 64-bit structures issue
  • #156 we drop clipboard packets that are too big - rather than causing network problems (bug was that we dropped the connection instead - oops!)
  • #52 another atom name issue, this time with Java apps
  • #8, #84 and #99 (dupe: #104): more clipboard atom problems
  • #11 win32 and osx clipboard ticket (old)