xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 3 years ago

#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 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!

Attachments (3)

xmodmap.txt (12.1 KB) - added by alex_shpak 4 years ago.
output of both xmodmap -pke and xmodmap -pm
xpra_info_0.txt (32.5 KB) - added by alex_shpak 4 years ago.
xpra info :0 for a session with the issue
xpra_info_100.txt (59.5 KB) - added by alex_shpak 4 years ago.
xpra info :100 for a session without the issue

Download all attachments as: .zip

Change History (13)

Changed 4 years ago by alex_shpak

Attachment: xmodmap.txt added

output of both xmodmap -pke and xmodmap -pm

Changed 4 years ago by alex_shpak

Attachment: xpra_info_0.txt added

xpra info :0 for a session with the issue

Changed 4 years ago by alex_shpak

Attachment: xpra_info_100.txt added

xpra info :100 for a session without the issue

comment:1 Changed 4 years ago by Antoine Martin

Status: newassigned

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 4 years ago by 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)

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by 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)

comment:5 Changed 4 years ago by 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..

comment:6 Changed 4 years ago by 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?

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 3 years ago by 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"

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to alex_shpak
Status: assignednew

Can I close this?

comment:10 Changed 3 years ago by Antoine Martin

Resolution: needinfo
Status: newclosed

Not heard back, closing.

Note: See TracTickets for help on using tickets.