Xpra: Ticket #561: Wrong keys produced when connecting from Windows laptop to Linux box in "shadow" mode

Keyboard presses seem to be completely messed up:

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!



Mon, 21 Apr 2014 20:23:55 GMT - alex_shpak: attachment set

output of both xmodmap -pke and xmodmap -pm


Mon, 21 Apr 2014 20:25:12 GMT - alex_shpak: attachment set

xpra info :0 for a session with the issue


Mon, 21 Apr 2014 20:25:39 GMT - alex_shpak: attachment set

xpra info :100 for a session without the issue


Tue, 22 Apr 2014 03:01:01 GMT - Antoine Martin: status changed

Confirmed:

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:


Tue, 22 Apr 2014 04:58:29 GMT - Antoine Martin:

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

But:


Tue, 22 Apr 2014 22:38:20 GMT - 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:

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.


Wed, 23 Apr 2014 03:27:08 GMT - 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)


Wed, 23 Apr 2014 04:57:05 GMT - 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:

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..


Wed, 23 Apr 2014 05:25:17 GMT - 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?


Sun, 27 Apr 2014 16:21:03 GMT - 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:


Sun, 27 Apr 2014 16:23:54 GMT - 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.


Fri, 09 May 2014 13:28:40 GMT - Antoine Martin: owner, status changed

Can I close this?


Sat, 17 May 2014 08:59:59 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing.


Sat, 23 Jan 2021 04:59:24 GMT - migration script:

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