on a wayland based client machine QT_QPA_PLATFORM=xcb does permit the client to run somewhat, however when I was testing this some time ago two problems resulted in an unusable experience
- client window resizing eventually stopped worked i.e dragging, fullscreen etc
- keyboard input was lost in the client window
arguably these may have the same root cause, my testing was only out of curiosity so it wasn't exhaustive. I eventually reverted to X11 for this and other performance reasons generally
Closing the client whilst running on wayland and restarting the client worked for a time then the same problems would occur.
Client machine was KDE, I am not sure what their wayland implementation was at the time.I have not motivation to move to wayland as x2go is my primary interface locally.
sai
On Wed, 22 May 2024 at 20:15, Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
Hm,
is this bug about the x2goclient or is about NX or even kdrive? A lot of guessing here....
On Stackoverflow ( https://stackoverflow.com/questions/21488072/what-is-the-use-of-various-qt-p... ) I find this regarding QT_QPA_PLATFORM:
xcb - Runs on an X11 server and is integrated into the X11 windowing environment. Generally it won't behave correctly without a window manager running as well. Can be made to work on Windows, given a Windows implementation of xlib, if you want to, say, serve applications from a Windows server to X11 thin terminals (typically Unix boxes).
So if the user has Wayland this is the wrong setting for the client side, at least for the x2go client qt code. Depending on XWayland seems wrong to me here.
Clients inside the nx session are talking to the remote X server and would require Xwayland. So I _think_ the only component that should run with XWayland is the nxproxy. Setting the var you mentioned will have the side effect of nxproxy finding the XWayland X-server that was started for x2goclient. So a quick test would be to replace nxproxy by a wrapper script that runs nxproxy with XWayland. I have no experience in this wayland stuff, so I may be totally wrong. Until now I was under the impression that XWayland is starts automatically if a client tries to open a Display.
Uli
On Wed, May 22, 2024 at 8:15 AM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
HI
On Mo 20 Mai 2024 21:34:47 CEST, Ulrich Sibiller wrote:
Hi,
I can't troubleshoot this issue. I have removed X2goclient from the Debian Stable (Bookworm) install, including all config, but when installing it fresh, it still does crash with a Segsev, is this bug known? I can't use X2go anymore on Linux, it just fails, without a way to find out what breaks. This issue has blocked me for many months now, it works on Windows, but most of my machines are running Linux.
Anybody have an idea what I can try next?
Thanks,
Markus
Hello,
your bug report is a bit "unspecific". What desktop environment /
window
manager are you using? What kind of session? Where are you connecting to? How is your session configured? Have you tried pyhoca-cli and / or pyhoca-gui?
Uli
On Mon, May 20, 2024 at 3:54 AM Sagittarius-A Black Hole < nigratruo@gmail.com> wrote:
Maybe it is about this issue? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042816
What is the best approach to address this. As X2Go Client interacts with the remote X session, it surely would make sense to launch the complete X2Go Client process via QT_QPA_PLATFORM=xcb and require XWayland to run. Is that a viable approach? Where should we enforce that (that being the switched from Wayland display to X11 display)?
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user