#561 closed defect (needinfo)
Wrong keys produced when connecting from Windows laptop to Linux box in "shadow" mode
Reported by: | alex_shpak | Owned by: | alex_shpak |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | platforms | Version: | 0.12.x |
Keywords: | Cc: |
Description
Keyboard presses seem to be completely messed up:
- pressing
a
prints space - pressing
s
prints4
- pressing
d
executesF2
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!
Attachments (3)
Change History (14)
Changed 8 years ago by
Attachment: | xmodmap.txt added |
---|
Changed 8 years ago by
Attachment: | xpra_info_100.txt added |
---|
xpra info :100
for a session without the issue
comment:1 Changed 8 years ago by
Status: | new → assigned |
---|
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
comment:2 Changed 8 years ago by
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)
comment:3 Changed 8 years ago by
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.
comment:4 Changed 8 years ago by
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)
comment:5 Changed 8 years ago by
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..
comment:6 Changed 8 years ago by
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?
comment:7 Changed 8 years ago by
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"
comment:8 Changed 8 years ago by
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.
comment:9 Changed 8 years ago by
Owner: | changed from Antoine Martin to alex_shpak |
---|---|
Status: | assigned → new |
Can I close this?
comment:10 Changed 8 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
Not heard back, closing.
comment:11 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/561
output of both
xmodmap -pke
andxmodmap -pm