Keyboard presses seem to be completely messed up:
a
prints space
s
prints 4
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!
output of both xmodmap -pke
and xmodmap -pm
xpra info :0
for a session with the issue
xpra info :100
for a session without the issue
Confirmed:
-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:
r6146 mostly fixes this, and is a good candidate for backport to v0.12.x (fairly self contained)
But:
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.
doesn't have
keyboard.keycode
orkeyboard.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)
Here's an example of a key that works from Linux clients, but not from win32. Shadow server debug output with -d keyboard
:
get_keycode(117, Page_Down, ('control',)) non-native keymap, translation lookup: 117
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..
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?
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:
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.
Can I close this?
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/561