On Tue, Mar 26, 2019 at 10:13 AM Mihai Moldovan <ionic@ionic.de> wrote:
- On 3/25/19 2:10 PM, Ulrich Sibiller wrote:
For testing you could try without ssh-agent or with the one of the current openssh.
Sure, that's the quickest workaround... I just switched to no-agent auth for testing.
Naturally, though, I wasn't able to reproduce the problem with the current master version. Everything was working fine as far as the keyboard was concerned.
It might be related to that commit, but I don't know. ctrl->num_groups is obviously zero in XkbAdjustGroup()/xkbUtils.c, but I have no idea what that actually means. The code in question does look a bit shady (for instance, it checks for group >= ctrls->num_groups and later might set group %= ctrls->num_groups, which obviously is a bad idea if both group and ctrls->num_groups is zero, but I have the suspicion that that should never have been the case in the first place.
I don't know what "groups" are in this context neither.
Keyboard groups, as described here: http://soc.if.usp.br/manual/x11proto-kb-dev/xkbproto.html#Keyboard_State
I somehow doubt that commit caused the problem, though. If the clone mechanism works fine, that change shouldn't cause any problems. There's probably no harm in cloning the config, even though we later sync up using xmodmap (other than a race condition, i.e., there MIGHT be a problem if we first sync up using xmodmap and then nxagent changes the whole keyboard settings again).
_maybe_ introducing a newer version of the xkb code also requires additional initialization (t.i. cloning more states from the real X server) which I might have missed somewhere.
Seems to be yet another weird problem that can only be reproduced with user accounts from NIS, but I have no idea why that might be. As far as I remember,
I cannot think of any reason why NIS users should behave different from local users (after all, NIS is just a nameservice like ldap or local files). The only thing that comes to mind is some central configuration that is only pulled in for NIS users.
Roberts home directories are not even coming via NFS so the home dir should be available at the time nxagent/x2goagent starts and - in that case - tries to block keyboard file creation by making a directory. However, nx-libs-3.5.99.18-0.0build1.0.git20190208.3237.heuler.fc29.x86_64 is quite old and I recently synced the master branch up with Arctica Project's master branch again, which means that it has 3.5.99.19 + the last two commits on top of it. Maybe it's worthwhile to retest with that.
I'm wary of releasing 3.5.99.19 to X2Go land, though, since I did notice a different problem in my test of an XFCE session on a Devuan Unstable machine: for some reason I didn't have xfce4-terminal installed and the default terminal application was set to qterminal. That started up, but only worked for a few seconds, after which it froze up. x2goagent/nxagent used 100 % of one CPU thread at that point and even after killing qterminal it continued to do so for a few minutes, after which it settled down with occasional 100 % CPU spikes (but it does that without having ever started qterminal, too, so I won't worry about it. My machine's test CPU is a pretty bad one - Intel Atom 1.8 GHs).
This looks like the app is using OpenGL. Does it work if you disable GLX?
Hopefully that's not a general problem with Qt5 applications?
Well, it depends on the standard (system) configuration for Qt apps. It Qt is configured to use OpenGL most apps will suffer from this.
Uli