Hi Uli, Attached a new session.log without any ibus mentioning - still the same issue: only the first copy and then every second copy succeed.
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. About the setup: 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. 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. Greets Jens > > Ulrich Sibiller <ulrich.sibil...@gmail.com> hat am 4. April 2025 um 00:17 > geschrieben: > > 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.sibil...@gmail.com> wrote: > > > > > > > > thanks, review will take some time.... > > > > Uli > > > > On Tue, Mar 25, 2025 at 12:00 PM Jens Reyer > > > > <jens.re...@leberrohstoffe.com> wrote: > > > > > > > > > > > > > Hi > > > > > > sorry for the late reply. I made my answers inline: > > > > > > Ulrich Sibiller <ulrich.sibil...@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 > > > > > > > > > > >
session.log.2025-04-07_no_ibus.gz
Description: GNU Zip compressed data
_______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
