Xpra: Ticket #176: clipboard doesn't work

I'm struggling to get clipboard working in 0.4.1:

On Debian Wheezy (both on server and client) copying text to clipboard (either from menu or keyboard) blanks clipboard contents of the remote machine.

Let's say I select and copy something in remote application, then trying to paste to local application: it pastes nothing and previous clipboard content disappears.

Exactly the same behaviour can be observed the other way: when I copy text to clipboard from local application, clipboard contents of remote application disappear.

Any ideas?

Thank you.



Sat, 11 Aug 2012 08:26:17 GMT - Antoine Martin: status changed

Changing:

#debug = log.info
debug = log.debug

to:

debug = log.info
#debug = log.debug

in clipboard_base.py can give us a lot more debug diagnostics messages.

I will try what you describe as soon as I can (about a week). Bear in mind that not all clipboard content types can be serialized and sent over to the other end, that some applications do weird things (Qt apps in particular IIRC), that clipboard managers simply break havoc by constantly requesting the contents of the clipboard, etc... Which app did you have problems with? Or was this all apps?


Sat, 11 Aug 2012 08:27:29 GMT - onlyjob:

Apparently this is a regression because 0.4.0 works perfectly.


Sat, 11 Aug 2012 08:43:06 GMT - Antoine Martin:

Hmm, that's odd, all I can see that is clipboard related in 0.4.1:

There are some further fixes due for 0.4.2:


Sat, 11 Aug 2012 09:45:16 GMT - onlyjob:

Thanks for hints.

I reckon something went wrong in r1230 - I reverted all changes introduced to

xpra/xposix/xclipboard.py

with the attached patch and it fixed the problem.

Yes, both machines are amd64, sorry for not mentioning it.

Cheers, Dmitry.


Sat, 11 Aug 2012 09:45:56 GMT - onlyjob: attachment set

patch: partial revert of r1230


Sat, 11 Aug 2012 16:16:27 GMT - أحمد المحمودي: attachment set


Sat, 11 Aug 2012 16:17:36 GMT - أحمد المحمودي:

I think the patch can be reduced as per fix-clipboard.diff (note: hand crafted diff file, but the idea should be clear)


Sun, 12 Aug 2012 00:08:24 GMT - Antoine Martin:

Hmm, there is something odd going on here. We can't just change the struct.pack without changing the corresponding struct.unpack - this is also used in gdk_clipboard.py for atoms and fixes known bugs.

Also, according to #11 this changeset fixes a warning which does look like a size issue (see 11#comment:3)

And obviously there's the actual X11 docs, see for example:

Now the latter is confusing me slightly since it talks about padding 32 bits rather than packing into 64... I think this needs looking into by placing know values in there and seeing how they're actually represented.


Sun, 12 Aug 2012 01:27:40 GMT - onlyjob:

I'll be happy to help testing this issue when you realise the best way to fix it. :)


Sun, 12 Aug 2012 05:53:53 GMT - Antoine Martin:

Thanks - if you can provide log samples from both client and server with debug enabled for clipboard as per comment:1, that may allow me to fix the bug sooner (since I'm not seeing the problem here on my 64-bit laptop - tried both trunk and 0.4.x branch). Also, please apply the debug change in r1314, or even better, test using trunk to also check if the bug is still present there (just in case - also the debug output in trunk shows the event time which is helpful for piecing things back together).


Sun, 12 Aug 2012 08:17:07 GMT - onlyjob:

Here it is:

## 0.4.1 (unpatched, both server and client) do NOT work:

### Paste to remote application @client:

process clipboard packet type=clipboard-request
process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
get_contents(TARGETS,<function got_contents at 0x24a0b18>)
got_contents(ATOM,32,72)

### Paste to remote application @server:

do_selection_request_event(<gtk.gdk.Event at 0x1888be8: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>)
do_selection_get(<GtkSelectionData at 0x7fffddc50440>,0,390684085)
get clipboard from remote handler id=0
process clipboard packet type=clipboard-contents
process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32
clipboard wire -> raw: ('ATOM', 32, 'atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']) -> '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00'
got clipboard contents(0)=36 (type=ATOM, format=32)
get clipboard from remote result(0)={'data': '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32}
do_selection_get(<GtkSelectionData at 0x7fffddc50440>,0,390684085) calling selection_data.set(ATOM,32,36)
do_selection_request_event(<gtk.gdk.Event at 0x1888be8: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>)

As far as I can see all applications are affected.

Also I noticed this may be a server-side issue: if I connect to xpra 0.4.1 that I patched by reverting xpra/xposix/xclipboard.py to 0.4.0 state from unpatched 0.4.1 clipboard works both ways.

Here is a client log for such case:

### Copy to clipboard @client:

do_selection_clear_event(<gtk.gdk.Event at 0x17bbfd0: GDK_SELECTION_CLEAR selection=PRIMARY, target=, property=>) selection=PRIMARY
send clipboard token: PRIMARY
do_selection_clear_event(<gtk.gdk.Event at 0x17bbfd0: GDK_SELECTION_CLEAR selection=CLIPBOARD, target=, property=>) selection=CLIPBOARD
send clipboard token: CLIPBOARD

### Paste to remote application @client (works):

process clipboard packet type=clipboard-request
process clipboard request, request_id=11, selection=CLIPBOARD, local name=CLIPBOARD, target=UTF8_STRING
get_contents(UTF8_STRING,<function got_contents at 0x18517d0>)
got_contents(UTF8_STRING,8,5)

I will test trunk and report ASAP.

Cheers, Dmitry.


Sun, 12 Aug 2012 08:43:34 GMT - onlyjob:

### trunk r1314 both server and client (do NOT work)

## Server log (paste to remote app):

2012-08-12 18:36:57,453 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>)
2012-08-12 18:36:57,455 target for CLIPBOARD: 'TARGETS'
2012-08-12 18:36:57,455 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>) target=TARGETS, selection=CLIPBOARD
2012-08-12 18:36:57,455 do_selection_get(<GtkSelectionData at 0x7fff10466f80>, 0, 541091)
2012-08-12 18:36:57,455 get clipboard from remote handler id=0
2012-08-12 18:36:57,467 process clipboard packet type=clipboard-contents
2012-08-12 18:36:57,467 process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32
2012-08-12 18:36:57,467 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)
2012-08-12 18:36:57,468 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)=[161L, 71L, 31L, 162L, 163L, 135L, 134L, 132L, 136L]=['\xa1', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\xa2', '\x00', '\x00', '\x00', '\xa3', '\x00', '\x00', '\x00', '\x87', '\x00', '\x00', '\x00', '\x86', '\x00', '\x00', '\x00', '\x84', '\x00', '\x00', '\x00', '\x88', '\x00', '\x00', '\x00']
2012-08-12 18:36:57,468 clipboard wire -> raw: ('ATOM', 32, 'atoms', ('text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS')) -> '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00'
2012-08-12 18:36:57,468 got clipboard contents(0)=36 (type=ATOM, format=32)
2012-08-12 18:36:57,468 get clipboard from remote result(0)={'data': '\xa1\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa2\x00\x00\x00\xa3\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32}
2012-08-12 18:36:57,469 do_selection_get(<GtkSelectionData at 0x7fff10466f80>,0,541091) calling selection_data.set(ATOM, 32, <type 'str'>:36)
2012-08-12 18:36:57,494 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>)
2012-08-12 18:36:57,494 target for CLIPBOARD: 'COMPOUND_TEXT'
2012-08-12 18:36:57,495 do_selection_request_event(<gtk.gdk.Event at 0x3036fd0: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>) target=COMPOUND_TEXT, selection=CLIPBOARD

## Client log (paste to remote app):

2012-08-12 18:36:57,545 process clipboard packet type=clipboard-request
2012-08-12 18:36:57,545 process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
2012-08-12 18:36:57,545 get_contents(TARGETS,<function got_contents at 0x358f500>)
2012-08-12 18:36:57,550 unpack(<gtk.Clipboard object at 0x2ed9730 (GtkClipboard at 0x301b340)>, <GtkSelectionData at 0x2cba1c0>, <type 'NoneType'>:0)
2012-08-12 18:36:57,550 unpack(..) type=ATOM, format=32, data=<type 'str'>:72
2012-08-12 18:36:57,551 got_contents(ATOM, 32, <type 'str'>:72) data=[143, 0, 0, 0, 0, 0, 0, 0, 71, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0, 0, 0, 0, 0, 144, 0, 0, 0, 0, 0, 0, 0, 121, 0, 0, 0, 0, 0, 0, 0, 138, 0, 0, 0, 0, 0, 0, 0, 140, 0, 0, 0, 0, 0, 0, 0, 141, 0, 0, 0, 0, 0, 0, 0, 142, 0, 0, 0, 0, 0, 0, 0], str(data)=�G�y����
2012-08-12 18:36:57,551 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72:['\x8f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x90', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'y', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8a', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8c', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8d', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8e', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00']) using gdk atom code
2012-08-12 18:36:57,552 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atoms=[<GdkAtom 0x8f = 'text/plain'>, <GdkAtom 0x47 = 'UTF8_STRING'>, <GdkAtom 0x1f = 'STRING'>, <GdkAtom 0x90 = 'TEXT'>, <GdkAtom 0x79 = 'COMPOUND_TEXT'>, <GdkAtom 0x8a = 'TARGETS'>, <GdkAtom 0x8c = 'MULTIPLE'>, <GdkAtom 0x8d = 'TIMESTAMP'>, <GdkAtom 0x8e = 'SAVE_TARGETS'>]
2012-08-12 18:36:57,552 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atom_names=['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']
2012-08-12 18:36:57,552 clipboard raw -> wire: ('ATOM', 32, '\x8f\x00\x00\x00\x00\x00\x00\x00G\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00\x00\x00y\x00\x00\x00\x00\x00\x00\x00\x8a\x00\x00\x00\x00\x00\x00\x00\x8c\x00\x00\x00\x00\x00\x00\x00\x8d\x00\x00\x00\x00\x00\x00\x00\x8e\x00\x00\x00\x00\x00\x00\x00') -> ('atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS'])

Sun, 12 Aug 2012 09:12:46 GMT - Antoine Martin:

thanks. this sample is from a qt app, right? do you get the same problem with an xterm? had problems with qt before, see #84

it also looks like the atoms aren't being filtered, maybe because the target does not match? here - does it fix the problem if you force the atom filtering to apply? you want to remove "COMPOUND_TEXT" and "SAVE_TARGETS".

they may have got removed accidentally by using the "wrong" code previously if those were ending up in the highest 32 bits.


Sun, 12 Aug 2012 14:20:45 GMT - onlyjob:

You're right, with unmodified 0.4.1 to my surprise pasting to 'xterm' worked but check 'kwrite' and I'm sure you'll see the problem...

So far I tried to remove the following from 0.4.1 (xpra/xposix/xclipboard.py) but it didn't help:

     atom_names.remove("SAVE_TARGETS")
     atom_names.remove("COMPOUND_TEXT")

Thanks.


Sun, 12 Aug 2012 14:42:18 GMT - Antoine Martin:

sorry, i meant the opposite: you want those two lines to fire everytime, even when the 'if' statement would not normally fire.


Sun, 12 Aug 2012 15:16:30 GMT - onlyjob:

Ops, sorry... Now I tried removing 'if' around 'atom_names.remove' but this alone didn't fix the problem in 0.4.1.

Thank you.


Sun, 12 Aug 2012 16:52:03 GMT - Antoine Martin:

Downloading 200MB of stuff just to get 'konsole' - sigh..


Sun, 12 Aug 2012 17:22:27 GMT - onlyjob:

Oh boy... :) Personally I'm addicted to Konsole. :)

Thank you for all your effort. You're doing a great work.

Much appreciated.


Sun, 12 Aug 2012 17:37:50 GMT - Antoine Martin:

OK, 200MB later and I finally got to see this "bug", which very much looks like another qt bug to me and explains why the previously broken code made it work with qt: it was discarding half the atoms (at random: whichever atoms ended up in the higher 32 bits) and ended up discarding the ones that qt does not like (more on that below).

So, r1315 adds the necessary code to make qt apps work again, but this is still commented out because I would much prefer finding a solution that does not also impair well behaved applications. Until then, to make it work, just uncomment the "#discard_targets" line which is prefixed with "#for qt". Works for me. Please confirm if this also works for you.

Why I think this is a qt bug: whenever we get a do_selection_request_event with one of the targets that qt apps barf on, we never get the corresponding do_selection_get, and the only thing in between those two calls is a plain gtk call to gtk.Invisible.do_selection_request_event. Not much else we can do here. It probably tries to do something very clever and fails miserably. During my testing I also saw some clipboard loops where the qt app repeatedly requests the same clipboard contents... sigh.


Mon, 13 Aug 2012 02:54:21 GMT - Antoine Martin:

Hang on a second... maybe I was completely wrong about this being a qt bug.

I am now totally confused about what the size of atoms should be when packed as structs (see for example r1317 - I tried using a '@Q' struct packing there, as the docs say I should? - but that failed)

Then I double-checked the size of GdkAtoms and since these are longs, changed the packing code to use native longs in r1318 and now qt apps seem to work without specific hacks.

I will definitely need to check all this again once I've had some proper sleep/rest (brain currently on strike), because it may just be that this change has the same effect as the previous "wrong" patch: discarding the atoms placed in the high 32-bits and therefore not really fixing the issue.

Testing/feedback welcome, especially with qt or Java apps - and apps that use more than just string clipboard (ie: utf8, etc)


Mon, 13 Aug 2012 03:03:48 GMT - onlyjob:

Sure, I'll help with testing. (Though I won't be able to check Java app...) This is a blocker for us as in Debian we can't ship package with known problem of copy/paste to of from QT apps...

Please take a good care of yourself and let us know when you ready. :)

By the way for debian packaging we have only two things left to do: fix this problem and introduce post-build testing #177 (minor).

Thank you.


Mon, 13 Aug 2012 10:25:16 GMT - Antoine Martin:

Unless someone can find an app that still exhibits clipboard problems, this ticket will be closed. I will also backport it to 0.3.x and 0.4.x later.

FYI: if Debian is not going to stick with the 0.3.x branch that I created specifically for it (sigh..), then it should go with 0.5.x instead, as it is in great shape now that this bug is fixed - the only thing holding up its release is the fact that I haven't got access to my VMs to test on and make builds for win32/OSX. (eta: end of the week) I have no intention of supporting end-of-line branches for much longer. Also bear in mind that future releases will drop support for versions older than 0.5 (due to missing raw protocol features and new encoding formats)


Mon, 13 Aug 2012 11:43:25 GMT - Antoine Martin: status changed; resolution set

Backported to 0.4.x and 0.3.x branches in r1320

Feel free to re-open if you find a problem.


Mon, 13 Aug 2012 12:12:28 GMT - onlyjob:

Thank you, tomorrow I'll test and report.

Regarding Debian release, don't you worry - Wheezy will be released with 0.3.x. We're in pre-release freeze now and at this time policy discourage new uploads without a very-very good reason.

Also we need to synchronise with transition of 'cython' - at this time its new version (required to build 0.4.x) is in 'experimental' only.

As you can see we have all the time we need to properly prepare new release. Recently I've made many packaging improvements and we will use all of those for 0.5 when you finish it. :)

I'm glad that's my packaging of 0.4.1 provided you with useful feedback.

Let's be in touch. Even if we make 0.4.x available from 'unstable' for some time you can be sure 0.5 will replace it soon enough. You know, I'm an active user now. :)

I can't thank you enough for a fantastic technology that you've made available. I'm about 20 years in the industry and I'm convinced that xpra is the most superior remote access technology ever.

I'm indebted to you for your work.

Cheers, Dmitry.

P.S. If you're going to release 0.5 in a matter of weeks 0.4 will not stand a chance to hit 'unstable'. :)


Mon, 13 Aug 2012 12:17:08 GMT - Timo Juhani Lindfors:

onlyjob, if you want to help with Debian work please subscribe to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680244 so that I get your name and email address :-)


Mon, 13 Aug 2012 14:28:27 GMT - onlyjob:

r1320 works well with 0.4.1 Thanks.


Tue, 14 Aug 2012 14:04:24 GMT - onlyjob: status, version changed; resolution deleted

I tried latest trunk r1314 but the same problem is still there: it pastes nothing to remote application 'kwrite'.

## paste to remote app (server log):

2012-08-14 23:55:26,707 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>)
2012-08-14 23:55:26,708 target for CLIPBOARD: 'TARGETS'
2012-08-14 23:55:26,708 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=TARGETS, property=_QT_SELECTION>) target=TARGETS, selection=CLIPBOARD
2012-08-14 23:55:26,708 do_selection_get(<GtkSelectionData at 0x7fffb6e5e600>, 0, 134926973)
2012-08-14 23:55:26,708 get clipboard from remote handler id=1
2012-08-14 23:55:26,715 process clipboard packet type=clipboard-contents
2012-08-14 23:55:26,715 process clipboard contents, selection=CLIPBOARD, type=ATOM, format=32
2012-08-14 23:55:26,716 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)
2012-08-14 23:55:26,716 _munge_wire_selection_to_raw(atoms, ATOM, 32, <type 'tuple'>:9)=[159L, 71L, 31L, 160L, 161L, 135L, 134L, 132L, 136L]=['\x9f', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\xa0', '\x00', '\x00', '\x00', '\xa1', '\x00', '\x00', '\x00', '\x87', '\x00', '\x00', '\x00', '\x86', '\x00', '\x00', '\x00', '\x84', '\x00', '\x00', '\x00', '\x88', '\x00', '\x00', '\x00']
2012-08-14 23:55:26,716 clipboard wire -> raw: ('ATOM', 32, 'atoms', ('text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS')) -> '\x9f\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa0\x00\x00\x00\xa1\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00'
2012-08-14 23:55:26,716 got clipboard contents(1)=36 (type=ATOM, format=32)
2012-08-14 23:55:26,717 get clipboard from remote result(1)={'data': '\x9f\x00\x00\x00G\x00\x00\x00\x1f\x00\x00\x00\xa0\x00\x00\x00\xa1\x00\x00\x00\x87\x00\x00\x00\x86\x00\x00\x00\x84\x00\x00\x00\x88\x00\x00\x00', 'type': 'ATOM', 'format': 32}
2012-08-14 23:55:26,717 do_selection_get(<GtkSelectionData at 0x7fffb6e5e600>,0,134926973) calling selection_data.set(ATOM, 32, <type 'str'>:36)
2012-08-14 23:55:26,746 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>)
2012-08-14 23:55:26,746 target for CLIPBOARD: 'COMPOUND_TEXT'
2012-08-14 23:55:26,747 do_selection_request_event(<gtk.gdk.Event at 0x1b99f80: GDK_SELECTION_REQUEST selection=CLIPBOARD, target=COMPOUND_TEXT, property=_QT_SELECTION>) target=COMPOUND_TEXT, selection=CLIPBOARD

paste to remote app (client log):

2012-08-14 23:55:26,710 process clipboard packet type=clipboard-request
2012-08-14 23:55:26,710 process clipboard request, request_id=1, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
2012-08-14 23:55:26,710 get_contents(TARGETS,<function got_contents at 0x7f7d0802a488>)
2012-08-14 23:55:26,711 unpack(<gtk.Clipboard object at 0x1de76e0 (GtkClipboard at 0x1ed6b90)>, <GtkSelectionData at 0x1bc0200>, <type 'NoneType'>:0)
2012-08-14 23:55:26,712 unpack(..) type=ATOM, format=32, data=<type 'str'>:72
2012-08-14 23:55:26,712 got_contents(ATOM, 32, <type 'str'>:72) data=[142, 0, 0, 0, 0, 0, 0, 0, 71, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0, 0, 0, 0, 0, 143, 0, 0, 0, 0, 0, 0, 0, 120, 0, 0, 0, 0, 0, 0, 0, 137, 0, 0, 0, 0, 0, 0, 0, 139, 0, 0, 0, 0, 0, 0, 0, 140, 0, 0, 0, 0, 0, 0, 0, 141, 0, 0, 0, 0, 0, 0, 0], str(data)=�G�x����
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72:['\x8e', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'G', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x1f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8f', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', 'x', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x89', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8b', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8c', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x8d', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00']) using gdk atom code
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atoms=[<GdkAtom 0x8e = 'text/plain'>, <GdkAtom 0x47 = 'UTF8_STRING'>, <GdkAtom 0x1f = 'STRING'>, <GdkAtom 0x8f = 'TEXT'>, <GdkAtom 0x78 = 'COMPOUND_TEXT'>, <GdkAtom 0x89 = 'TARGETS'>, <GdkAtom 0x8b = 'MULTIPLE'>, <GdkAtom 0x8c = 'TIMESTAMP'>, <GdkAtom 0x8d = 'SAVE_TARGETS'>]
2012-08-14 23:55:26,713 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:72) atom_names=['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS']
2012-08-14 23:55:26,714 clipboard raw -> wire: ('ATOM', 32, '\x8e\x00\x00\x00\x00\x00\x00\x00G\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x00\x00\x00\x00\x8f\x00\x00\x00\x00\x00\x00\x00x\x00\x00\x00\x00\x00\x00\x00\x89\x00\x00\x00\x00\x00\x00\x00\x8b\x00\x00\x00\x00\x00\x00\x00\x8c\x00\x00\x00\x00\x00\x00\x00\x8d\x00\x00\x00\x00\x00\x00\x00') -> ('atoms', ['text/plain', 'UTF8_STRING', 'STRING', 'TEXT', 'COMPOUND_TEXT', 'TARGETS', 'MULTIPLE', 'TIMESTAMP', 'SAVE_TARGETS'])

Interestingly if server is latest (fixed) 0.4.1 pasting from client trunk works.

Cheers, Dmitry.


Tue, 14 Aug 2012 14:09:07 GMT - Antoine Martin:

r1314 is not the latest:

Please re-test and close ticket if needed.


Tue, 14 Aug 2012 14:14:22 GMT - onlyjob: status changed; resolution set

My bad I missed few commits - it is working perfectly in trunk r1320.

Please ignore the noise. Sorry...


Sat, 23 Jan 2021 04:47:35 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/176