| View previous topic :: View next topic |
| Author |
Message |
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
 Posted: Thu Sep 13, 2018 12:51 am Post subject: X11 _XKB_RULES_NAMES issue in X2Go client - [SHELVED] |
 |
|
All but 1 of my X2Go defined sessions no longer have responsive arrow or 'insert', 'home', 'page up', 'page down', 'delete' or 'end' keys.
For some reason, on all these X2Go client sessions and any new ones I create, the root window's xproperty _XKB_RULES_NAMES is not being set. This is without regard to which host (including local.host), account or WM I use. This isn't the end of the world since I just take the 'num lock' off and use the numeric keypad for arrow keys instead. Inconvenient and annoying but not the end of the world.
I found the discussion in this X2Go bug# 674 message #18 to be helpful in understanding the bad behavior. The basic suggestion is to properly set the xproperty _XKB_RULES_NAMES. Unfortunately, 'xprop' can't do this as the values to be set are strings and xprop doesn't really do strings.
Among the three cases, _XKB_RULES_NAMES looks like this: | logged in KDE on host: | # xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "" |
| logged into sole working X2Go session: | $ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "base", "pc105", "us", ",", "," |
| all the other X2Go sessions: | $ setxkbmap -model pc105 -layout us
Couldn't interpret _XKB_RULES_NAMES property
Use defaults: rules - 'base' model - 'pc105' layout - 'us'
Error loading new keyboard description |
The above linked comment's author wrote a python script: xproperty to be able to set the X11 root window's xproperties which are string values. I tried running it but got an error: | xproperty.py: | # ./xproperty.py _XKB_RULES_NAMES
Traceback (most recent call last):
File "./xproperty.py", line 5, in <module>
import Xlib.display
ModuleNotFoundError: No module named 'Xlib' |
I'm assuming here that my environment is different enough for the script to not work.
I also located a 'c' program: xsetprop which purports to be able to do the same but I haven't had a chance to try it and I'm also not a developer so I'm not practiced at 'make' etc.
Does anyone have any further suggestions on how to deal with this?
I do have some idea on why this is happening but that's a whole 'nother post.
updated 2018-09-16
Upon further testing with the Windows based X2Go client ( x2goclient-4.1.2.0-2018.06.22 ), this issue doesn't occur (works as expected). I have the qt based 'net-misc/x2goclient-4.1.2.1' package installed on all my linux PCs. I cannot downgrade to 'net-misc/x2go-4.1.1.1' due to multiple 'x2goclient' emerge related errors associated with 'dev-qt/qtwidgets-5.11.1'. | Sample: | src/printwidget.cpp:77:36: error: invalid use of incomplete type ‘class QButtonGroup’
QButtonGroup* bg=new QButtonGroup();
^
In file included from /usr/include/qt5/QtWidgets/qcheckbox.h:44,
from /usr/include/qt5/QtWidgets/QCheckBox:1,
from ./ui_printwidget.h:14,
from src/printwidget.h:22,
from src/printwidget.cpp:18:
/usr/include/qt5/QtWidgets/qabstractbutton.h:53:7: note: forward declaration of ‘class QButtonGroup’
class QButtonGroup;
^~~~~~~~~~~~ |
At this point, I'm guessing the 'x2goclient-4.1.2.1' release was to permit compiling with qt 5.11.x releases. This is just a guess on my part. I'm going to try to bring this to the attention to upstream.
updated 2018-09-18
I've worked with upstream in irc trying to find the root cause of the problem. At the present time, there should never be a time when the root window's _XKB_RULES_NAMES property is unset with the apparent sole special case exception under circumstances I don't know anything about when the login originates from a iOS based machine. The root cause of the problem may have to do with some interaction with X11 as installed on my workstation and not with X2Go.
At the moment, I cannot do any further testing because Florida Power & Light was kind enough to add interest to my life by sloppily switching feeds at the local substation while I was doing an @world updates. I'm mostly recovered from this but I still can't do a graphical login on my workstation using my main account. I'll come back to inestigating this X2Go issue after I finish cleaning up the mess FP&L left me.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
 |
anon_gentoo
n00b
Joined: 04 Dec 2018
Posts: 1
|
| Posted: Tue Dec 04, 2018 3:32 pm Post subject: |
|
|
I've run into a similar issue on Fedora. Over time three out of my four workstations stopped responding to the keys that you mentioned in your OP. What follows is what I've gleaned about the issue.
I normally run a local X session on my workstations since they are not headless and I just access those X sessions by using the "Connect to local desktop" feature of x2goclient. When I set up a new machine and access it via x2goclient, everything works OK for a a month or so when suddenly I have the same issue you are facing. Reboots, full fedora system upgrades, etc, make no difference.
However, if I initiate a NEW session via x2go, the keyboard issue is not present. So I've compared the X keyboard configurations between the two instances to try and figure out the differences.
On the faulty sessions:
| Code: |
>xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
>setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
|
On the working sessions:
| Code: |
>xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "base", "pc105", "us", "", ""
>setxkbmap -print
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(pc105)" };
xkb_geometry { include "pc(pc105)" };
};
|
Obviously the local X session is using evdev (which is failing) and the sessions created by x2go are using xfree86 with the base rules (which are working). I'm guessing that whatever keyboard translation is taking place between x2go and evdev is failing. Why it works initially, I'm not certain.
Here's the weird thing. Sometimes when I reset the keycodes in the local desktop session to xfree86 using | Code: | | setxkbmap -keycodes "xfree86" |
, the broken keys will start working again (although the output of setxkbmap does not change)! And I can toggle the key functionality between the working and broken state by issuing | Code: | | setxkbmap -keycodes "evdev" |
and | Code: | | setxkbmap -keycodes "xfree86" |
But this has only happened twice in my testing and it is far more likely that the above command does nothing when issued.
So that leads me to believe that perhaps the DE is overriding the keycode settings, which would explain the sporadic behavior of the keyboard settings in x2go.
By chance, are you using MATE in your x2go desktop sessions? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
