Wrong keys produced when connecting from Windows laptop to Linux box in "shadow" mode

[alex_shpak]

Keyboard presses seem to be completely messed up:

• pressing a prints space
• pressing s prints 4
• pressing d executes F2 shortcut

Happens only when connecting to session started with xpra shadow :0. Didn't see such bugs reported before, although #86 might be somewhat related.

I think it might be related to the fact that xpra info :100 ("normal" xpra session started with xpra start :100) shows a lot of entries for keyboard.keycode and keyboard.keysym, while for xpra start :0 there is none.

OS is Windows XP connecting to Linux Mint 16 Petra a.k.a. Ubuntu 13.10
I might as well LiveCD any Linux on that laptop.

both client and server are version 0.12.3

Keyboard layouts on Win laptop: us(default), ru
Keyboard layouts on Linux PC:

lex@Shuttle ~ $ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+no+ru(winkeys):2+inet(evdev)+group(alt_shift_toggle)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
lex@Shuttle ~ $ setxkbmap -query
rules:      evdev
model:      pc105
layout:     no,ru
variant:    ,winkeys
options:    grp:alt_shift_toggle

for key a, xev prints this line if I press it directly on Linux box:

state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,

and this line if I press a when connected by Xpra from Windows:

state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,

for key a, ​gtk_view_keyboard.py on Linux box prints this line:

down a                       a   97        38        0 0 ['2']

while for a same key GTK_Keyboard_Test.exe on Windows laptop prints this line:

down a                       a   97        65        0 0 ['2']

Probably that's where keycode 65 comes from!

[alex_shpak]

output of both xmodmap -pke and xmodmap -pm

[alex_shpak]

xpra info :0 for a session with the issue

[alex_shpak]

xpra info :100 for a session without the issue

[Antoine Martin]

Confirmed:

• added more keyboard debug logging in r6142
• added info on the -d keyboard debug switch to wiki/Keyboard

With this I can see that we assume we are using a native keymap (more on "native" keymap bugs in #483).

What we should be doing instead:

• not use "native" mode
• populate the keycode translation table with the current server keyboard mappings

[Antoine Martin]

r6146 mostly fixes this, and is a good candidate for backport to v0.12.x (fairly self contained)

But:

• some key combinations still do not work from win32 clients (to be investigated)
• the win32 and osx shadow servers still need work (the keyboard code has lots of dependencies on X11 which will need to be split out and injected - not v0.12.x material)

[alex_shpak]

Tested on my configuration (version 0.12.3 with above patch applied manually) and can confirm that it's better than before.

Some keys have issues, indeed. Most notably, Alt and win/Super/Meta keys have some issues:

• Left Alt is recognized as None
• Win is recognized as Alt or None
• Right Alt produces series of keystrokes, including numLock, and sometimes keeps firing events even after being release.

Also note that this behavior is inconsistent.

Most of these issues are not there when connecting to "normal" session.

I think that it might be because r6146 uses "default" keymap, which is different from those I have on the server. xpra info :0 doesn't have keyboard.keycode or keyboard.keysym entries.

[Antoine Martin]

doesn't have keyboard.keycode or keyboard.keysym entries

That's because the information was not shown for shadow servers, this is fixed in r6158.

This does not try to solve the problems of trying to map win32 key events to their X11 counterpart... which is a much more difficult task. On top of that, we have client-side workarounds for some keys already (like AltGr, see the mess in r1760, r1759, etc)

[Antoine Martin]

Here's an example of a key that works from Linux clients, but not from win32. Shadow server debug output with -d keyboard:

• Linux client:

  get_keycode(117, Page_Down, ('control',)) non-native keymap, translation lookup: 117
  

• win32 client:

  get_keycode(34, Page_Down, ('control',)) non-native keymap, translation lookup: 34
  

We don't find the Page_Down key for some reason (..), and we fallback to using the client keycode as-is, and so the Linux clients works because it uses the same keycode, but for win32 clients we end up sending random keycodes instead...
Maybe we should only do this for x11 clients running against x11 servers, which is what the is_native_keymap flag was meant to capture, but this is now re-used for shadow servers and ends up meaning something else..

[Antoine Martin]

Fixed in r6159: we need the gtk keynames in the translation lookup table.
This fixes win32 clients with shadow servers, and r6160 re-uses this code to hopefully improve keyboard mapping for regular servers too.

Quite a few changesets backported to v0.12.x in r6163.
@alex_shpak: does that (mostly?) fix things for you?

[alex_shpak]

Oops, forgot to comment: yes, this fixes most of the issues (I can type letters now), although some other keys still have issues. Do you want me to list them or will you find them yourself? :) Some of them are:

• symbol keys to the right of digits/letters
• "win" and "alt" keys
• "pageUp", "Page Down"

[Antoine Martin]

Do you want me to list them

If you want them fixed... Please include as much detail as possible. I did try PageUp and PageDown and both worked here. Please also try trunk server, just in case.

[Antoine Martin]

Can I close this?

[Antoine Martin]

Not heard back, closing.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/561