Closed totaam closed 4 years ago
Xpra_cmd-gtk_view_kb_2019-05-17_11-51-15.png
(59.1 KiB)kb-bug-report.zip
(72.7 KiB)From the bug report zip file, this system seems to be running Ubuntu 16.04 and xpra GTK3 client version 3.0 r22449. Is the client MS Windows? What version?
Please capture the
-d keyboard
output of just when you press the keys that are not mapped properly.
Replying to [comment:1 Antoine Martin]:
From the bug report zip file, this system seems to be running Ubuntu 16.04 and xpra GTK3 client version 3.0 r22449. Is the client MS Windows? What version?
Win10 r22633
Please capture the
-d keyboard
output of just when you press the keys that are not mapped properly.Is it possible to do that?
It would help a lot with the server bug reports, since,
-d keyboard
means my lockscreen password is coming up on the logs
Is it possible to do that?
tail -f
on the logfile and copy only the portion corresponding to the event.
I've added a greek layout to my ms windows 7 system, connected to an ubuntu 16.04 shadow server.
All the keys worked just fine.
Unless you can provide easily reproducible steps, I will have to close this ticket as 'needinfo'.
I believe
xpra shadow :0 -d keyboard
mixes mouse events :/[36m2019-06-18 13:18:13,945 update_mouse(3, 5386, 620, 906, 620) current=(1016, 776), client=1, show=True[0m [36m2019-06-18 13:18:13,947 filtered_modifiers_set([])=set([])[0m [36m2019-06-18 13:18:13,947 filtered_modifiers_set([])=set([])[0m
xpra-2301-client.txt
(10.0 KiB)xpra-2301-server-2019-06-18_13-20-44.txt
(9.4 KiB)I believe xpra shadow :0 -d keyboard mixes mouse events :/ I don't understand what that means, in any case this doesn't provide any steps to reproduce the problem.
I am not sure what do you mean you don't understand.
I started a shadow server with -d keyboard, and I see mouse events (mixed with the keyboard events)
Additionally, I added debug run from both ends as an attachment - and I believe that it is complete debug information according to your request.
I started a shadow server with -d keyboard, and I see mouse events (mixed with the keyboard events) Pointer events include the modifiers state. So you will see things like
filtered_modifiers_set..
and some adjustments made on occasion. That's because if you change shift or alt state whilst moving over another window, we need to synchronize that state when moving back over xpra's window, as some applications use this state.Additionally, I added debug run from both ends as an attachment - and I believe that it is complete debug information according to your request. As per comment:4, I asked for exact steps to reproduce the problem. How to configure my test systems to trigger this issue.
I don't have any special configuration in-place. Except the
/etc/xpra/80_lock.conf
, I simply provide any configuration straight to the command line for reproducibilityOn both stations I have US layout active (but GR installed also), I start
xpra-shadow
remotely, I am just pressing<>?|
keys in a sublime window (see that it "gives">>?>
), and close the session.
Like I said, I cannot reproduce the problem at all using a default configuration. So please provide the details required so that I can configure my test systems exactly like yours. (as per keyboard / bug reporting wiki pages:
setxkbmap -query
from the server session, etc)
Have you opened [/attachment/ticket/2301/kb-bug-report.zip] ?
It contains
setxkbmap -query
rules: evdev model: pc105 layout: us
and a couple of other things too
Configuration on the server is "pretty clean too":
log-file (used) = 'display-$DISPLAY.log' <type 'str'> log-file (default) = '$DISPLAY.log' <type 'str'> microphone (used) = 'disabled' <type 'str'> microphone (default) = 'off' <type 'str'> min-quality (used) = 20 <type 'int'> min-quality (default) = 30 <type 'int'> min-speed (used) = 50 <type 'int'> min-speed (default) = 30 <type 'int'> pings (used) = 1 <type 'int'> pings (default) = 5 <type 'int'> speaker (used) = 'disabled' <type 'str'> speaker (default) = 'on' <type 'str'> start-on-last-client-exit (used) = 'bash -c 'echo now I will touch ; touch /run/user/1000/xpra-test-`date +%s`*, 'bash -c 'echo now I will fail! ; `date`*, 'bash -c 'echo now I will lock ; . /run/user/1000/dbus-session; gnome-screensaver-command -l'' <type 'list'> start-on-last-client-exit (default) = [] <type 'list'> webcam (used) = 'no' <type 'str'> webcam (default) = 'auto' <type 'str'>
I can reproduce this problem with the MacOS client and a Fedora host on the latest beta; happy to post relevant logs or help debug this issue.
The fixes from #2560 may well help with this. @stdedos: Does the latest beta server build help?
If not, then #2574 may help too.
On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-25205.zip) I don't seen any difference:
[[Image(2301-xpra-gtk-kb-via-shadow-Screenshot from 2020-02-12 21-50-13.png)]]
Of course, you retargeted this to v4, so I cannot really test this anytime soon.
2301-xpra-gtk-kb-via-shadow-Screenshot from 2020-02-12 21-50-13.png
(36.3 KiB)On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-25205.zip) I don't seen any difference What am I looking at? Did you run the tool within the xpra session whilst connected from the win32 client? What keys did you press exactly? And what was the active keyboard layout at that point? The only change that is not in 3.0.6 is r25174 + r25175. This may eventually land in 3.1.x
Replying to [comment:16 Antoine Martin]:
On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-25205.zip) I don't seen any difference What am I looking at? Did you run the tool within the xpra session whilst connected from the win32 client?
I shadowed via Windows to Ubuntu, I pressed the keys, and took the screenshot using the
gnome-screenshot
in Ubuntu. I wanted to make a better visualization, showing the same window in Windows; I'll try again today if I can make itWhat keys did you press exactly? And what was the active keyboard layout at that point?
The non-Shift-keys are shown correctly. So, with en-us layout, in order:
- ,
- Shift+,
- .
- Shift+.
- \
- Shift+\
Can you add that on that window too?
- Always show the active layout.
- At the beggining, and for every layout change: Add a new line with the new layout
The only change that is not in 3.0.6 is r25174 + r25175. This may eventually land in 3.1.x
At the beggining, and for every layout change: Add a new line with the new layout Done in r25236.
Backport to 3.0.x?
Or can I just update my local version with this?
Unfortunately, I am not able to "cleanly" prepare the visualization I wanted, it seems that the executable cannot passively listen to keyboard events; it needs to be focused.
Also, there is no r25236+ version for Windows, and I cannot patch an
exe
. (additionally 25205GTK_Keyboard_Test.exe
is broken, I used 24039)So, here is the visualization roughly (Screenshot from the Windows client, including the shadowed Keyboard State Tool): [[Image(2301-Xpra_cmd_2020-02-18_12-27-28.png)]]
2301-Xpra_cmd_2020-02-18_12-27-28.png
(115.6 KiB)Also, there is no r25236+ version for Windows, and I cannot patch an exe. Ah... ZIP format:
Xpra-Python3-x86_64_4.0-[r25280](../commit/0c33b602f176df735f5288af28205f46a016e200).zip
is there now.
Replying to [comment:21 Antoine Martin]:
Also, there is no r25236+ version for Windows, and I cannot patch an exe. Ah... ZIP format:
Xpra-Python3-x86_64_4.0-[r25280](../commit/0c33b602f176df735f5288af28205f46a016e200).zip
is there now.<3 It appears to be so much more convenient (and contained).
Same cx_Freeze error :/
Same cx_Freeze error :/ Same as? There is no mention of a cx_Freeze error in this ticket.
Same as? Same as the image from comment:20: [/attachment/ticket/2301/2301-Xpra_cmd_2020-02-18_12-27-28.png]
.. the image above has it (the middle window is from 25205)
I found also this one, but I think it's the same as the above one: [[Image(xpra-gi-explorer_2020-02-12_21-48-03.png)]]
Still happening in r25314 The keyboard fix that may help with this is server-side... and in v4 only for now. I will try to reproduce.
The more I see the image [/attachment/ticket/2301/2301-Xpra_cmd_2020-02-18_12-27-28.png] the more I wonder:
From where does that 'fi' layout come? My laptop "has some association" with Finnish (because it is provisioned in Finland), but my Xenial server should not have - it is also in Finland, but I installed and configured it myself and has no Finnish-related stuff at all:
$ locale LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC=el_GR.UTF-8 LC_TIME=el_GR.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=el_GR.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=el_GR.UTF-8 LC_NAME=el_GR.UTF-8 LC_ADDRESS=el_GR.UTF-8 LC_TELEPHONE=el_GR.UTF-8 LC_MEASUREMENT=el_GR.UTF-8 LC_IDENTIFICATION=el_GR.UTF-8 LC_ALL=
(except the update mirrors and the one command
while IFS= read -r i ; do setxkbmap -device "$i" -layout fi ; done < <(xinput --list | grep 'Dell KB216 Wired Keyboard' | grep -oP '(?<=id=)\d+')
which I only execute physically on the server, because I have two USB keyboards attached to the computer - one of them has a Finnish layout)
xpra-gi-explorer_2020-02-12_21-48-03.png
(46.8 KiB)From where does that 'fi' layout come? run
xpra/platform/keyboard.py
On x11, this will usually query the X11 keyboard using the equivalent to
setxkbmap -query
.but my Xenial server should not have For seamless servers: the xpra server's vfb will be configured using the same settings as the client's. During the initial connection setup, the client sends its keyboard information and the server does its best to mirror it. So if the client detects
fi
then that's what the server will use.For shadow servers, we don't modify anything at all server side, we just look up the key definitions and try our best to find a match. The newer v4 builds try harder.
Replying to [comment:28 Antoine Martin]:
From where does that 'fi' layout come? run
xpra/platform/keyboard.py
On x11, this will usually query the X11 keyboard using the equivalent to
setxkbmap -query
.$ python3 /usr/lib/python3/dist-packages/xpra/platform/keyboard.py Modifiers: * Alt_L : mod1 * Alt_R : mod1 * Caps_Lock : lock * Control_L : control * Control_R : control * Hyper_L : mod4 * ISO_Level3_Shift : mod5 * Meta_L : mod1 * Mode_switch : mod5 * Num_Lock : mod2 * Shift_L : shift * Shift_R : shift * Super_L : mod4 * Super_R : mod4 Server Managed : None Missing from pointer events : mod2 Layout: 'us' Layouts: 'us' Variant: '' Variants: Options: Repeat: 500, 30
I have the Greek layout in
Alt+Shift
, but somehow is not detected :/ weirdbut my Xenial server should not have For seamless servers: the xpra server's vfb will be configured using the same settings as the client's. During the initial connection setup, the client sends its keyboard information and the server does its best to mirror it. So if the client detects
fi
then that's what the server will use.For shadow servers, we don't modify anything at all server side, we just look up the key definitions and try our best to find a match. The newer v4 builds try harder.
Does this ^^ work for Windows too?
And the Windows side:
Xpra-Python3-x86_64_4.0-[r25314](../commit/cef716c67fe8f1f1ff1380150d7587b14db17825)\Keyboard_info.exe Modifiers: Server Managed : None Missing from pointer events : lock keyboard layout code 0x409 identified as 'United States - English' : us Layout: 'us' Layouts: 'us', 'gr' Variant: '' Variants: Options: Repeat: 500, 33
So, now the keyboard layouts seem okay:
[[Image(Xpra-2301_cmd_2020-02-21_22-00-34.png)]]
but still the keys are the same weird keys
Xpra-2301_cmd_2020-02-21_22-00-34.png
(151.8 KiB)I'm really not sure how to reproduce this problem. The keys in your screenshot come up fine, both with 3.0.7-RC and 4.0-beta servers. How can I configure my win10 client PC with the exact same keyboard configuration as you?
Or alternatively, can you reproduce the bug with a command line specifying the keyboard options, ie: something like
xpra_cmd attach --keyboard-layout=us --keyboard-layouts=us,gr
The only problem I found so far is with the "Greek" layout activated, sending "control-C" to the server doesn't work. Will fix tomorrow.
I have no idea. I merely added the (modern) Greek language and keyboard, alongside English for my user. [[Image(xpra-2301-winsettings-language-ApplicationFrameHost_2020-03-05_21-01-40.png)]] This is a multi-user machine provisioned in Finland, with Finnish / English keyboard. [[Image(xpra-2301-language-region-welcome_screen-rundll32_2020-03-05_21-05-20.png)]]
Attaching with:
"Xpra-Python3-x86_64_4.0-[r25519](../commit/f9057e6fd70fff31eb2e9744132cafd5db367ff6)\xpra_cmd" attach ssh://user@ip/0 --ssh="plink -ssh -agent" --keyboard-layout=us --keyboard-layouts=us,gr --opengl=no --min-quality=20 --desktop-scaling=0.75 2020-03-05 20:53:24,914 Xpra GTK3 client version 4.0-[r25519](../commit/f9057e6fd70fff31eb2e9744132cafd5db367ff6) 64-bit 2020-03-05 20:53:24,916 running on Microsoft Windows 10 2020-03-05 20:53:24,978 Warning: failed to import opencv: 2020-03-05 20:53:24,979 No module named 'cv2' 2020-03-05 20:53:24,979 webcam forwarding is disabled 2020-03-05 20:53:26,055 GStreamer version 1.16.2 for Python 3.8.2 64-bit 2020-03-05 20:53:26,557 keyboard layout code 0x409 2020-03-05 20:53:26,559 identified as 'United States - English' : us 2020-03-05 20:53:27,110 keyboard settings: layout=us 2020-03-05 20:53:27,115 desktop size is 1600x900 with 1 screen: 2020-03-05 20:53:27,116 Default (423x238 mm - DPI: 96x96) workarea: 1600x860 2020-03-05 20:53:27,117 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131) 2020-03-05 20:53:27,117 downscaled to 75%, virtual screen size: 2133x1200 2020-03-05 20:53:27,118 Default (423x238 mm - DPI: 128x128) workarea: 2133x1147 2020-03-05 20:53:27,120 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 175x175) 2020-03-05 20:53:35,019 enabled remote logging 2020-03-05 20:53:35,032 Xpra GTK3 shadow server version 3.0.6-[r25174](../commit/86fdb78c7bf461e68008d62bac8a4bf54dd5f12c) 64-bit 2020-03-05 20:53:35,035 running on Linux Ubuntu 16.04 xenial 2020-03-05 20:53:35,038 remote desktop size is 6400x1440 2020-03-05 20:53:35,060 Attached to 172.16.57.121:22 2020-03-05 20:53:35,069 (press Control-C to detach) (xpra_cmd:8268): Pango-WARNING **: 20:53:35.748: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output. 2020-03-05 20:53:36,795 UI thread is now blocked 2020-03-05 20:53:37,462 UI thread is running again, resuming 2020-03-05 20:53:41,891 server is not responding, drawing spinners over the windows 2020-03-05 20:53:42,163 server is OK again 2020-03-05 20:55:13,765 unknown string message: 0xc286 / 0x0 / 0x0 2020-03-05 21:00:57,564 unknown string message: 0xc2aa / 0x707a4 / 0x2
And pressing in order: m,./ @ Shift+m,./ @ μ,./ @ Shift+μ,./ : [[Image(GTK_Keyboard_Test_2020-03-05_20-57-27.png)]]
GTK_Keyboard_Test_2020-03-05_20-57-27.png
(199.8 KiB)xpra-2301-language-region-welcome_screen-rundll32_2020-03-05_21-05-20.png
(21.8 KiB)xpra-2301-winsettings-language-ApplicationFrameHost_2020-03-05_21-01-40.png
(9.3 KiB)500px-KB_Greek.svg.png
(28.1 KiB)greek keyboard layout
Issue migrated from trac ticket # 2301
component: server | priority: major | resolution: fixed
2019-05-17 09:57:12: stdedos created the issue