[X2Go-Dev] Ten X2Go-KDrive bugs/oddities
Oleksandr Shneyder
o.shneyder at phoca-gmbh.de
Mon Jul 27 18:01:25 CEST 2020
Hi Stefan,
first of all, I never tried X2GoKdrive on Ubuntu, my customers are using
SLES, Open SUSE, RHEL and CentOS.I'm using debian for developing. So
maybe some issues are related to Ubuntu. I'll answer inline.
Am 16.07.20 um 03:38 schrieb Stefan Baur:
> Hi List, hHi Alex,
>
> Lately I was able to test a few more things with X2Go-KDrive, and I
> encountered some bugs/oddities with it.
>
> Maybe you could comment below which issues I should file as a bug, and
> what further info (like, screenshots, package versions, content of
> certain config files, ...) I should try to gather before filing it, to
> make debugging/fixing it easier?
>
> All tests were performed with an Ubuntu 18.04 LTS Client; and X2GoClient
> from the stable repository.
>
> The host ran on Debian 10.4, and was using the X2Go heuler repository,
> with the following X2Go-related packages:
>
> ii libx2go-log-perl
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all Perl
> X2Go::Log package
> ii libx2go-server-db-perl
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 amd64 Perl
> X2Go::Server:DB package
> ii libx2go-server-perl
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all Perl
> X2Go::Server package
> ii x2go-keyring
> 2019.08.21~git20190824.119+11.heuler.1 all GnuPG keys of
> all X2Go developers and the X2Go archive
> ii x2goserver
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 amd64 X2Go server
> ii x2goserver-common
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 amd64 X2Go Server
> (common files)
> ii x2goserver-extensions
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all X2Go Server
> (extension support)
> ii x2goserver-fmbindings
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all X2Go Server
> (file manager bindings)
> ii x2goserver-printing
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all X2Go server
> (printing support)
> ii x2goserver-x2goagent
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 amd64 X2Go Server's
> X2Go Agent Xserver
> ii x2goserver-x2gokdrive
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 amd64 X2Go Server's
> X2Go KDrive Xserver
> ii x2goserver-xsession
> 4.1.0.4-0x2go1.2~git20200228.1815+10.heuler.1 all X2Go Server
> (Xsession runner)
> ii xserver-x2gokdrive
> 0.0.0.1-0x2go1~git20200120.183+10.heuler.1 amd64 KDrive
> graphical server backend for X2Go Server
> ii libnx-x11-6:amd64
> 2:3.5.99.22-0~git20190928.3526+10.heuler.1 amd64 nxagent's
> libNX_X11 client-part library
> ii nx-x11-common
> 2:3.5.99.22-0~git20190928.3526+10.heuler.1 all nx-X11
> (common files)
> ii nxagent
> 2:3.5.99.22-0~git20190928.3526+10.heuler.1 amd64 Nested
> Xserver (aka NX Agent) supporting the NX compression protocol
>
> First issue/oddity:
> No matter which Desktop Environment is being used on the remote end, the
> local client window seems to snap to the top left position in an 800x600
> resolution (or maybe even smaller, like 640x480), then it resizes to the
> requested size. This can be seen during resume, where the resume happens
> on the 800x600 (or whatever) resolution, then the screen is resized, and
> you see "garbage" on the screen (cloned sections of the client window
> content), until it redraws the entire screen after resizing it properly.
> This takes about a second or so.
> This may also be the reason why in one particular situation (during
> another test, on a different setup) I saw the KDrive window getting
> stuck at that small size in the upper left corner - probably the
> "maximize" command didn't reach the window manager, or there was no
> window manager present, or something like that.
this is strange, I have never seen such behavior. Client window should
start in the resolution specified by the session setting. Maybe the
issue is related to your local window manager?
> Second issue/oddity:
> Only roughly every second attempt to resize the client-side KDrive
> window using the mouse works. The other attempts have it snap back to
> where it originally was, once you let go of the mouse button.
Maybe it's related to the first issue? We are using x2goclient on
Windows, KDE, XFCE and Gnome desktops without having this problem. I
suspect that your local window manager interfering with your mouse
interaction. What desktop environment are you using on the client? Can
you try it with another one?
> Third issue:
> At least in most of the desktop environments tested, both keyboard
> autodetection AND keyboard manual selection fails, so you're stuck with
> a US keyboard inside the session.
> The notable exception is GNOME, here, keyboard settings work, even in
> autodetection mode!
there is no mechanism yet in X2Go server to configure the keyboard
layout in the kdrive session according to x2go client configuration.
KDrive agent is starting as normal X-Server with default layout
pc105/us. I didn't yet make decision how to act here. The actions could
be different depending on the DE used on the server. At the moment user
can configure the keyboard using kbd configuration inside of the server
session. I don't see a big problem here.
> Fourth ... well, oddity:
> In Fullscreen sessions, the top-of-the-screen Config Bar's Minimize
> Button does not work unless fullscreen mode has been toggled off and on
> again.
also works for me without problems, maybe same issue as with #1,2 ?
> Fifth issue:
> The modes "Published Application" and "XDMCP" are selectable with
> KDrive, but do not do anything useful; "Single Application" is only
> useful together with KDrive when the application in question has a
> fullscreen mode (like "rdesktop -f")
yes, this should be done. Latest at the moment, when X2gokdrive losing
the state "Experimental". The real "rootless" single application mode
for KDrive should be also implemented at some point, but this requires
some development and at the moments I don't have requests from my
customers to do this.
> Sixth issue:
> The top-of-the-screen Config Bar has a button "Disconnect". This should
> be named "Suspend" (or "Disconnect and suspend"), to be more in line
> with current X2Go terminology, and to make it more clear to the user
> that this isn't terminating the session, but rather suspending it.
> Also, Ctrl-Alt-T should suspend the session just like in classic NX
> mode, but currently does nothing.
Ok, suspend instead of disconnect makes sense. About Ctrl-Alt-T, I'm not
sure. Anyway, it's not useful for me. More of that, this combination is
often used for another purposes (like open a terminal). For someone who
uses this combination on local desktop this could be really annoying.
>
> Seventh issue:
> LXQt complains on session startup that "global keyboard shortcut
> Ctrl-Alt-D for Desktop could not be registered" (Popup message)
No idea, I don't see how it could be a x2gokdrive issue.
> Eight issue:
> In Fullscreen mode (but not in windowed mode!), when using LXQt, MATE,
> XFCE or KDE, clicking the "Disconnect" button in the top-of-the-screen
> Config Bar does suspend the session, but any attempts at reconnecting
> lead to a client-side abort. The only way to recover is to either start
> X2GoClient with --no-autoresume, and terminating the session from the
> session chooser, or to log in via ssh and issue a x2goterminate-session
> command with the corresponding session ID.
This also newer happened to me. My customers using FS mode in about 80%
of cases. Maybe related to Ubuntu or your local window manager? This
needs more investigation.
>
> Ninth issue:
> KDE complains on session startup that I should enter Admin credentials
> for configuring a system update proxy?
>
> Tenth issue:
> GNOME complains on session startup that I should enter Admin credentials
> to update system repositories. (This popup appears even twice.)
Also not the issue of x2gokdrive. X2gokdrive from the sight of DE it's
just a regular X-Server. Does DE also asks for the admin password if
user starts it locally? Anyway, if we supposed to create workaround for
that it needs to be done in x2goserver, not in x2gokdrive.
regards,
Alex
> Kind Regards,
> Stefan Baur
>
--
-----------------------------------------------------------
Oleksandr Shneyder | Email: o.shneyder at phoca-gmbh.de
phoca GmbH | Tel. : 0911 - 14870374 0
Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9
D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de
HRB 196 658 | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x2go.org/pipermail/x2go-dev/attachments/20200727/0081b313/attachment.sig>
More information about the x2go-dev
mailing list