search

Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
1.9k stars 163 forks source link

xpra shadow: cannot type "|" "<" keys, all write ">" #2301

Closed totaam closed 4 years ago

totaam commented 5 years ago

Issue migrated from trac ticket # 2301

component: server | priority: major | resolution: fixed

2019-05-17 09:57:12: stdedos created the issue

Using xpra shadow :0, I cannot type the "|" and "<" characters. Using en-us as active kb layout (on both sides) all write ">".

I tried following the https://xpra.org/trac/wiki/Keyboard template, ...:

  • active keyboard layout(s): en-us*, el-gr (both) [[Image(Xpra_cmd-gtk_view_kb_2019-05-17_11-51-15.png)]]
  • gtk_view_keyboard.py (named GTK_Keyboard_Test.exe on MS Windows)

... but the steps seem too much:

  • client and server log output with the -d keyboard debugging switch
  • running both the server and the client with the debug option -d keyboard, or for very verbose debugging: -d keyboard,verbose

... I don't know how to work them:

  • input methods
  • keyboard related configuration setup/files
  • keyboard type
  • if the problem is affecting specific keys, you may want to use the environment variable XPRA_DEBUG_KEYSYMS=keyname1,keyname2 on the server to log the keyboard mapping process for those keys
  • xev output of the misbehaving key events

... they sound irrelevant:

  • whether the bug is also present with/without --no-keyboard-sync

... these could be automated in one script saving them:

  • setxkbmap -print and setxkbmap -query (both directly in the client if it supports those commands and in the xpra session)
  • Keymap_info.exe on MS Windows, or xpra/gtk_common/keymap.py everywhere else
  • xmodmap -pke and xmodmap -pm (again on both)
  • xkbprint -label name $DISPLAY

(#2299 was found during this ticket)

xpra start gnome-terminal sends the keys just right, it's probably a shadow-server-thing

totaam commented 4 years ago

2020-03-06 08:10:34: antoine commented

For my own reference, I believe the keyboard layout used is this one: [[Image(500px-KB_Greek.svg.png)]]

totaam commented 4 years ago

2020-03-06 10:15:49: stdedos commented

This is what it would look like physically:

[[Image(microsoft-500-wired.jpg)]]

totaam commented 4 years ago

2020-03-06 10:15:59: stdedos uploaded file microsoft-500-wired.jpg (46.8 KiB)

microsoft-500-wired.jpg

totaam commented 4 years ago

2020-03-06 12:51:38: antoine commented

I am very confident that this is fixed in r25529 so I've already backported the fix to the v3.0 branch in 25532. I managed to reproduce the problem using a Fedora server configured with 'us' layout. ('gb' layout doesn't have this problem because the default keycodes for 'less' and 'greater' are different..)

Note however that we still don't modify the server keymap, so we can't always find the Greek characters in the 'us' layout and some keys just won't work. To change that, we would need to introduce the option of modifying the server keymap in shadow mode. (we could then reconfigure the server as 'us' + 'gr' to ensure all the characters are mapped: #2630)

Other keymap debug improvements in r25530 + r25531, we will now also honour keysym debugging with shadow servers, ie:

XPRA_DEBUG_KEYSYMS=greater,less /usr/bin/python3 /usr/bin/xpra shadow

@stdedos: you can apply r25529 by hand, or use one of the latest 3.0.7-RC builds for xenial.

totaam commented 4 years ago

2020-03-06 21:47:56: stdedos commented

I haven't tested the above comment, and probably won't until next week. With that out of the way:

I don't know exactly how your implementation of pressing keys work, and probably you have had good reasons to implement it the way you did.

On a very high level, unoptimized, I would think this would work like so:

  • You record the key presses on the client side, along with the active layout
  • You translate the keyboard layout to the server's equivalent layout (if needed)
  • You apply this layout to the server (1)
  • You replay the key presses to the virtual keyboard device on the server
  • You reset the server layout to the original one

(1) On my server, I have two physical keyboards: One printed with the US keyboard layout, one with the !Finnish/Nordic one.

Whenever I want to type with the Finnish one, I run while IFS= read -r i ; do setxkbmap -device "$i" -layout fi ; done < <(xinput --list | grep 'Dell KB216 Wired Keyboard' | grep -oP '(?<=id=)\d+') which allows for both keyboards to have two different layouts (I haven't found a way to persist that, and this is effective until next time I press Alt+Shift to change to the Greek layout).

What you mentioned:

, so we can't always find the Greek characters in the 'us' layout and some keys just won't work.

is happening when the server is set on the Greek layout: I am fairly certain can find exactly zero letter characters that can be printed.

totaam commented 4 years ago

2020-03-07 04:08:29: antoine commented

On a very high level, unoptimized, I would think this would work like so: There is a lot more to keyboard mapping than you can possibly imagine.

  • You record the key presses on the client side, along with the active layout Not possible, you often don't know which layout caused which key to be pressed. Only the keysym. Also, you may get spurious key events from the OS, or some key events may be swallowed (ie: shortcuts, window does not have keyboard focus, etc).
  • You translate the keyboard layout to the server's equivalent layout (if needed) Sort of. But that has to be done at connection setup time because:
  • You apply this layout to the server (1) You can't. Changing layout takes a long time and triggers all sorts of unwanted system events.
  • You replay the key presses to the virtual keyboard device on the server Here is the hard part. Which key? X11 deals with keycodes, you need to find the right one to use, and take into account modifier keys (and press / unpress them on the fly if needed), layout groups, etc.
  • You reset the server layout to the original one As per above, that's not possible.

, so we can't always find the Greek characters in the 'us' layout and some keys just won't work. is happening when the server is set on the Greek layout: I am fairly certain can find exactly zero letter characters that can be printed. The default 'gr' X11 layout does not have any regular 'a-zA-Z' latin characters, see setkxmap -pke. To make those characters available, you have to configure your server with setxkbmap gr,us.

totaam commented 4 years ago

2020-03-10 12:54:50: stdedos commented

FINALLY we can close this. It works:

[[Image(Xpra-kb-tool_cmd_2020-03-10_14-47-55.png)]]

Client: Xpra-Python3-x86_64_4.0-r25568 Server: Xenial / 3.0.7-25532

     69 2020-03-10 14:42:20,332 Warning: remote clipboard request timed out
     70 2020-03-10 14:42:20,332  request id 16, selection=CLIPBOARD, target=TARGETS
     71 2020-03-10 14:44:28,567 New unix-domain connection received
     72 2020-03-10 14:44:28,567  on '/run/user/1000/xpra/user.linux-precision-t3620-0'
     73 2020-03-10 14:44:28,569 Handshake complete; enabling connection
     74 2020-03-10 14:44:29,568 New unix-domain connection received
     75 2020-03-10 14:44:29,568  on '/run/user/1000/xpra/user.linux-precision-t3620-0'
     76 2020-03-10 14:44:29,569 New unix-domain connection received
     77 2020-03-10 14:44:29,569  on '/run/xpra/user.linux-precision-t3620-0'
     78 2020-03-10 14:44:31,592 Error setting up client dbus instance:
     79 2020-03-10 14:44:31,592   org.freedesktop.DBus.Error.NoServer
     80 2020-03-10 14:44:31,592   Failed to connect to socket /tmp/dbus-xsapXOpCxN
     81 2020-03-10 14:44:31,592   Connection refused
     82 2020-03-10 14:44:31,593  automatic picture encoding enabled, also available:
     83 2020-03-10 14:44:31,593   h264, vp9, vp8, png, png/P, png/L, rgb24, rgb32, jpeg
     84 2020-03-10 14:44:31,595 Python/GTK3 Microsoft Windows 10 aero client version 4.0-[r25568](../commit/879a9b9a0bf68b7e04127f8e0e93c05133ec4cdb) 64-bit
     85 2020-03-10 14:44:31,595  connected from 'AA-000000' as 'user.linux' - 'user.win'
     86 2020-03-10 14:44:31,598 shadow server: setting default keymap translation
     87 2020-03-10 14:44:31,599 set_default_keymap: ('less', 1)=59
     88 2020-03-10 14:44:31,599 set_default_keymap: ('less', 3)=59
     89 2020-03-10 14:44:31,599 set_default_keymap: ('greater', 1)=60
     90 2020-03-10 14:44:31,600 set_default_keymap: ('greater', 3)=60
     91 2020-03-10 14:44:31,600 set_default_keymap: ('less', 0)=94
     92 2020-03-10 14:44:31,600 set_default_keymap: ('greater', 1)=94
     93 2020-03-10 14:44:31,600 set_default_keymap: ('less', 2)=94
     94 2020-03-10 14:44:31,600 set_default_keymap: ('greater', 3)=94
     95 2020-03-10 14:44:31,601 set_default_keymap: less=94
     96 2020-03-10 14:44:31,601 set_default_keymap: greater=60
     97 2020-03-10 14:44:31,606  client root window size is 2133x1200
     98 2020-03-10 14:44:31,636 client   1 @11.658 Xpra GTK3 shadow server version 3.0.7-25532 64-bit
     99 2020-03-10 14:44:31,638 client   1 @11.662  running on Linux Ubuntu 16.04 xenial
    100 2020-03-10 14:44:31,641 client   1 @11.664  remote desktop size is 6400x1440
    101 2020-03-10 14:44:31,707 client   1 @11.690 Attached to ip:22
    102 2020-03-10 14:44:31,707 client   1 @11.704  (press Control-C to detach)
    103 2020-03-10 14:44:32,904 Warning: not adding duplicate printer 'Microsoft Print to PDF'
    104 2020-03-10 14:44:32,905 Warning: not adding duplicate printer 'Send To OneNote 16'
    105 2020-03-10 14:44:32,905 Warning: not adding duplicate printer 'OneNote'
totaam commented 4 years ago

2020-03-10 12:55:22: stdedos uploaded file Xpra-kb-tool_cmd_2020-03-10_14-47-55.png (65.9 KiB)

Xpra-kb-tool_cmd_2020-03-10_14-47-55.png

totaam commented 4 years ago

2020-03-11 03:57:07: antoine commented

This caused a regression: #2632#comment:8

totaam commented 4 years ago

2020-03-16 15:48:31: antoine commented

And another regression: #2648.

totaam commented 4 years ago

2020-04-02 05:29:06: antoine commented

And another regression: #2702

I should not have made that change to the stable branch.

This ticket is similar to #1465.