-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XRDP Keyboard evdev support? #211
Comments
I'm going to move this to the xorgxrdp repository, as I think it's more relevant there. |
Hi @mhoffmann75 First of all, I must stress this isn't an area I know much about at all. This information may not be that useful, or maybe there's a better way to do this. The xorgxrdp driver (unsurprisingly) includes a keyboard driver. As part of this driver the rules set to use for the keyboard is specified. It appears to me to be hard-coded to If I apply this patch to diff --git a/xrdpkeyb/rdpKeyboard.c b/xrdpkeyb/rdpKeyboard.c
index 4061b53..f2491ca 100644
--- a/xrdpkeyb/rdpKeyboard.c
+++ b/xrdpkeyb/rdpKeyboard.c
@@ -82,7 +82,7 @@ xrdp keyboard module
#define N_PREDEFINED_KEYS \
(sizeof(g_kbdMap) / (sizeof(KeySym) * GLYPHS_PER_KEY))
-static char g_base_str[] = "base";
+static char g_base_str[] = "evdev";
static char g_pc104_str[] = "pc104";
static char g_us_str[] = "us";
static char g_empty_str[] = ""; I get the following in my xrdp session:-
With a UK keyboard I can't tell any difference in the mappings. A UK keyboard is really not very interesting though, compared to all the other keyboards out there. Maybe that is the same for you as well, but it's probably worth a try. |
Changing this in rdpKeyboard.c does indeed make the XRDP session come up with evdev keyboard instead of xfree86 base. But it instantly suffers from exactly the same special-character and cursor key problems that i had before with certain apps and switching to evdev on the fly via |
Thanks for the update. As I said, it's not an area I'm at all familiar with. The RDP client sends a keyboardLayout type over to the server during the initial connection setup. It might be worth checking this is correct, before X even gets involved. Again, with my UK keyboard, I get messages like the following in
|
I have changed the key codes and type in the rdpKeyboard.c accordingly to https://github.com/neutrinolabs/x11rdp/blob/devel/X11R7.6/rdp/rdpkeyboardevdev.c This seems to work for german keyboard from windows and mac os quite well. All keys seems to behave as expected and for all apps i was able to test. I guess this needs a lot more testing for different keyboards and languages. However this change would still break xorgxrdp support for non-evdev systems, so we might need some configure option to support both? |
That's interesting, but somewhat out of my knowledge to comment on I'm afraid. Have you had a chance to look in Thanks. |
Yes, i did check
Some rdp client software seems to negotiate a keyboard, which seems reasonable to me:
I will test some more with the changes i made and report back. |
Something else to throw into the mix for you - the I just ran Have a look at neutrinolabs/xrdp#180. It references neutrinolabs/xrdp#179 which you mention above, and may be responsible for the differences. In other words, on your system, it may be worth regenerating |
Thanks for pointing that out, but I had tried generating new keymap files while on evdev before but it did not change anything for me. I will take a closer look to find the actual differences. |
Hello. I have recently received a report from a CentOS server user I administer that On closer inspection, the problem was not identified in GNOME applications. The situation suggests that the problem only occurs in applications that refer directly to scancode and not Keysym. The situation is similar to issue #355. |
I applied the patch created @mhoffmann75 to xorgxrdp ver 0.9.19. The cursor keys now work correctly in applications that refer directly to the X11 scancode. I noticed in the process of creating the patch that the keyboard "/ ? I thought that xorgxrdp also needs a mechanism to judge the language and keyboard type and switch the X11 scancode. |
Is there a workaround that does not involve patching sources? |
@lostmsu - for now, stick for base rules for xrdp, or use the VNC backend. There are limitations to this - media keys won't work, and applications with hard-coded X11 keycodes won't work either. I'm working in this area currently, so I'm hoping something will land in |
Is it possible to switch XRDP to evdev keyboard rules or at least make it compatible?
All ubuntu 20.04 flavors (gnome, xfce, ...) seem to use 'evdev' keyboards:
However when i connect to this same machines via XRDP i get a 'base' rule with a 'xfree86' setting:
As far as i understand this might be intended to make it compatible for Xvnc sessions. However i don't use Xvnc sessions as i connect to Xorg sessions via xorgxrdp extensions.
So, how can i switch XRDP to evdev to make it behave exactly like it does on the X console?
My problem arises with certain applications (mostly remote consoles) that do work on the machine's X console as intended but having keyboard issues when i access my machine via XRDP. They all suffer the same problem of ignoring alt-gr keys (german keyboard @, , ...) and actually no cursor keys - only cursor-down seems to be enter.
The same effect appears if i switch keyboard to 'evdev' in running XRDP session via
setxkbmap -rules evdev
Then all applications have this same problem. So it seems to me that these applications won't play with 'base' mode but need 'evdev' rules?
So question is, what can be done to make XRDP play with 'evdev' rules. I tried this on ubuntu 20.04, xubuntu20.04 with xrdp 0.9.12 (ubuntu repos) and 0.9.18 built from source - all the same. Any ideas?
Is this a bug or a limitation of the current implementation?
neutrinolabs/xrdp#179 seems to imply that there is a way to switch to evdev rules (breaking Xvnc - but that would be ok for me) but it does not tell what needs to be done to achieve this. As this is quite old i'm not sure if it still applies.
The text was updated successfully, but these errors were encountered: