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