On Tue, Mar 26, 2019 at 10:13 AM Mihai Moldovan <io...@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 _______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
