Hi Markus,
check your env vars, specifically XDG_SESSION_TYPE will tell you wayland or x11 ..... as for versions dpkg -l | grep wayland might get you there.
x2go doesn't work with wayland at all unless that has changed recently, so the server end always needs to be x11. Remembering wayland is a moving target. Largely though it depends on how you've configured your target session. If you are running kdrive that is its own manager seperate to both wayland and x11.
On a wayland client machine, the client runs in the x11 compatibility layer (xwayland) you can list xwayland based windows with xlsclients -l
arch doco has some good general info on wayland https://wiki.archlinux.org/title/wayland
sai
On Wed, 5 Jun 2024 at 12:10, Sagittarius-A Black Hole <nigratruo@gmail.com> wrote:
Hi all,
using QT_QPA_PLATFORM=xcb does fix the issue for me, I can log in and use X2goclient.
This is from a Debian Stable (Bookworm) laptop running Plasma (KDE) to a server running the very same software. How can I find the version of the components being used? At this point, I'm not even sure anymore if I'm still using some X11 components or just wayland. I know there is a compatibility layer too, which makes it more confusing. I would assume that X2go (based on certain X11 libs (NX / Nomachine) does not even work without that compatibility layer or am I mistaken about that?
Thank you for the workaround, it makes my life a lot easier, as I depend on X2go for daily terminal server use.
Thanks,
Markus
On Wed, 22 May 2024 at 15:31, sairuk <sairuk@gmail.com> wrote:
on a wayland based client machine QT_QPA_PLATFORM=xcb does permit the
- 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
client to run somewhat, however when I was testing this some time ago two problems resulted in an unusable experience 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
-- Por sperto kaj lerno ne sufiĉas eterno.