<!DOCTYPE html>
<html><head>
<meta charset="UTF-8">
</head><body><p>Hi Uli,<br><br>Attached a new session.log without any ibus mentioning - still the same issue: only the first copy and then every second copy succeed.<br><br>For this I uninstalled ibus on both client and server. The session.log is from starting a terminal, then "libreoffice --calc /home/localadmin/test.ods" and then 7 ctrl+c / ctrl+v.<br><br>About the setup:</p><p>Client (PC, Linux Mint 22.1, twm) and server (Proxmox VM, Debian trixie/sid (testing/unstable), twm, libreoffice 25.2.2.2) are on the same 1Gbit LAN. For testing so far I changed all mentioned characteristics for both server and client (PC/VM, Linux Mint 22/22.1 / Debian, Gnome/Mate/Windows (client)/twm, LAN/VDSL). Using a PC as server or local session helps a bit.</p><p>So in my setup the relevant factor is Libreoffice 24 or above (last known good version was Libreoffice 7.3.7) in a x2go session with clipboard client to server enabled.<br><br>Greets<br>Jens</p><p><br></p><blockquote><p>Ulrich Sibiller <ulrich.sibiller@gmail.com> hat am 4. April 2025 um 00:17 geschrieben:</p><p>Hi,</p><p>I have not fully understood yet what's going with your setup and will<br>go on with checking.</p><p>However, I see ibus-related communication which I do not see on my<br>setup. I have no experience with ibus or X input methods in general. I<br>see ibus working with selections and _maybe_ it triggers a bug in my<br>code that has been undetected yet. I would like to ask you to repeat<br>testing after disabling/uninstalling ibus. I am wondering if you<br>installed that on purpose or not.</p><p>Uli</p><p>On Wed, Mar 26, 2025 at 10:55 PM Ulrich Sibiller</p><p><ulrich.sibiller@gmail.com> wrote:<br>></p><blockquote><p>thanks, review will take some time....</p><p>Uli</p><p>On Tue, Mar 25, 2025 at 12:00 PM Jens Reyer</p><p><jens.reyer@leberrohstoffe.com> wrote:<br>></p><blockquote><p>Hi</p><p>sorry for the late reply. I made my answers inline:</p><p>Ulrich Sibiller <ulrich.sibiller@gmail.com> hat am 17. März 2025 um 21:35 geschrieben:</p><p>Hello again,</p><p>I had a look at the logfile. It's been a while since I worked on the<br>clipboard code. But I _think_ there are a few things you should test:</p><p>restrict clipboard to text only: add X2GO_NXAGENT_DEFAULT_OPTIONS+="<br>-textclipboard" to /etc/x2go/x2goagent.options on the server side and<br>start a NEW session (no reconnect). Does that help?</p><p>No, same behavior.</p><p>But I kept this setting for all further tests.</p><p>not sure what exactly you have been doing while creating the sessionlog. But I can seen "caja" on the server side requesting clipboard.<br>Please try to run a session without caja (which is a file manager,<br>unclear what it does with selections).</p><p>See new session.log without any caja mention, from a client with twm/xterm to a session with twm on the server. There I started xterm, then did a "libreoffice --calc /home/localadmin/test.ods" and did several ctrl+c ctrl+v in that calc document.</p><p>it _looks_ like something on the client side is requesting theclipboard when you are doing your tests. The question is what program<br>is doing that. If possible run a few programs on the client side,<br>preferably only a very simple session (fvwm twm or so) and an xterm.<br>Run x2goclient from there.<br>To find out what program on the client side is requesting the<br>clipboard you can check the server log file for lines like this:<br>nxagentHandleSelectionRequestFromXServer: Received<br>SelectionRequestEvent from real server: selection [529][CLIPBOARD]<br>target [469][TARGETS] requestor<br>[display[nx,options=/tmp/.x2go-localadmin/C-localadmin-50-1742211621_stDMATE_dp24/options:50.0]/0xe09e31]<br>destination [386][GDK_SELECTION] time [13640727]. The bold number is<br>the requestor. You can check that with xwininfo -id <number> on the<br>client.</p><p>The bold marking went missing, so I just tested all ids.</p><p>From client mate to server twm I always get "No such window ...", e.g.</p><p>me@client:~$ xwininfo -id 531<br>X Error: 9: Bad Drawable<br>Request Major code: 14<br>ResourceID in failed request: 0x213<br>Serial number of failed request: 3<br>xwininfo: error: No such window with id 0x213.</p><p>Then I tested from the twm/xterm client to a twm/xterm session on the server, see the attached Bug1633_nxagentHandleSelectionRequestFromXServer.log</p><p>there's an option to include the clipboard content (or rather thedata being transferred) in the session log in DEBUG mode. This helps<br>in identifying what stage we are in. Change #undef<br>PRINT_CLIPBOARD_CONTENT_ON_DEBUG to #define and recompile</p><p>Done, see new session.log.</p><p>while at it you could also try to change the timeout for theclipboard transfer. I hardcoded 5s when I wrote all this and it was ok<br>for me ever since. But YMMV. #define CONVERSION_TIMEOUT 5000. In your<br>log I see errors like this "nxagentConvertSelection: got new request<br>before timeout expired on previous request, notifying failure to<br>client [20] (addr [0x557c39ea2f40] PID [18630] Cmd<br>[/usr/lib/libreoffice/program/soffice.bin])". This means that the<br>previous clipboard-related communication has not finished when soffice<br>starts another request which then is denied. So this indicates that<br>some answer from the client side is still due. I suspect that this<br>answer is never sent so your diagnosis that every second paste is<br>working might in fact resemble a 5s pattern. Meaning: you can only<br>successfully paste every 5s, but not quicker. So I suggest to decrease<br>the timeout to 2s or so and see if that makes a difference for you.<br>One thing here is strange here, though: Doing a copy in soffice on the<br>server side makes soffice the clipboard owner. So while you are<br>working inside soffice there should be no communication to the client<br>that awaits any answer. Which again leads me to the suspicion that<br>there's some clipboard manager involved.</p><p>First I tried waiting for 15 seconds after copying: this does NOT help.</p><p>Then I recompiled with #define CONVERSION_TIMEOUT 2000, same behavior, see new session.log</p><p>x11 clipboard transfers are size restricted. That means that biggerselections are to be transferred to the requestor in multiple packets.<br>nx does not support this currently, so you are restricted to 256kB. Is<br>it possible that your selection is bigger than that?</p><p>No, its always just a few characters.</p><p>I also see SelectionClear requests from the client side. Which alsoindicates there's something dealing with clipboard on the client side.</p><p>I still see SelectionClear in the new twm/xterm to twm/xterm session.log, but I'm not sure which side they are from.</p><p>I played around with these tools:<a href="https://github.com/phillbush/xcliputils">https://github.com/phillbush/xcliputils</a> Using xclipowner -w you can<br>watch if the clipboard owner changes. Run that on the client and then<br>do clipboard stuff in libreoffice on the server. The owner as printed<br>by xclipowner should never change except for the first time. If it<br>does we have another indication of a clipboard-manager-in-the-middle<br>attack ;-)</p><p>From client Mate to server twm a successful ctrl+c results in</p><p>0x03C0016A</p><p>and a failed ctrl+c results in a</p><p>0x00000000<br>0x03C0016A</p><p>From twm/xterm client to a twm/xterm session on the server both failed and successful ctrl+c results in</p><p>0x00E0016A</p><p>Thanks and greets</p><p>_______________________________________________<br>x2go-dev mailing list<br>x2go-dev@lists.x2go.org<br><a href="https://lists.x2go.org/listinfo/x2go-dev">https://lists.x2go.org/listinfo/x2go-dev</a><br></p></blockquote></blockquote></blockquote></body></html>