xpra icon
Bug tracker and wiki

Opened 10 months ago

Last modified 7 days ago

#2301 assigned defect

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

Reported by: stdedos Owned by: Antoine Martin
Priority: major Milestone: 4.0
Component: server Version: 2.5.x
Keywords: Cc:

Description

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)


  • 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

Attachments (8)

Xpra_cmd-gtk_view_kb_2019-05-17_11-51-15.png (59.1 KB) - added by stdedos 10 months ago.
kb-bug-report.zip (72.7 KB) - added by stdedos 10 months ago.
xpra-2301-client.txt (10.0 KB) - added by stdedos 9 months ago.
xpra-2301-server-2019-06-18_13-20-44.txt (9.4 KB) - added by stdedos 9 months ago.
2301-xpra-gtk-kb-via-shadow-Screenshot from 2020-02-12 21-50-13.png (36.3 KB) - added by stdedos 2 weeks ago.
2301-Xpra_cmd_2020-02-18_12-27-28.png (115.6 KB) - added by stdedos 10 days ago.
xpra-gi-explorer_2020-02-12_21-48-03.png (46.8 KB) - added by stdedos 7 days ago.
Xpra-2301_cmd_2020-02-21_22-00-34.png (151.8 KB) - added by stdedos 7 days ago.

Download all attachments as: .zip

Change History (38)

Changed 10 months ago by stdedos

Changed 10 months ago by stdedos

Attachment: kb-bug-report.zip added

comment:1 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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.

comment:2 in reply to:  1 Changed 9 months ago by stdedos

Replying to 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

comment:3 Changed 9 months ago by Antoine Martin

Is it possible to do that?

tail -f on the logfile and copy only the portion corresponding to the event.

comment:4 Changed 9 months ago by Antoine Martin

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'.

comment:5 Changed 9 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

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

Changed 9 months ago by stdedos

Attachment: xpra-2301-client.txt added

Changed 9 months ago by stdedos

comment:6 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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.

comment:7 Changed 9 months ago by stdedos

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.

comment:8 Changed 9 months ago by Antoine Martin

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.

comment:9 Changed 9 months ago by stdedos

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 reproducibility

On 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.

comment:10 Changed 9 months ago by Antoine Martin

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)

comment:11 Changed 9 months ago by stdedos

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'>

Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:12 Changed 5 months ago by Antoine Martin

Milestone: 3.04.0
Owner: changed from stdedos to Antoine Martin
Status: newassigned

comment:13 Changed 3 months ago by mjlbach

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.

comment:14 Changed 3 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

The fixes from #2560 may well help with this.
@stdedos: Does the latest beta server build help?

If not, then #2574 may help too.

comment:15 Changed 2 weeks ago by stdedos

On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-r25205.zip) I don't seen any difference:


Of course, you retargeted this to v4, so I cannot really test this anytime soon.

comment:16 Changed 2 weeks ago by Antoine Martin

On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-r25205.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

comment:17 in reply to:  16 Changed 2 weeks ago by stdedos

Replying to Antoine Martin:

On v3.0.6-r25174 (client Xpra-Python3-x86_64_4.0-r25205.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 it

What 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

Last edited 13 days ago by stdedos (previous) (diff)

comment:18 Changed 13 days ago by Antoine Martin

At the beggining, and for every layout change: Add a new line with the new layout

Done in r25236.

comment:19 Changed 13 days ago by stdedos

Backport to 3.0.x?

Or can I just update my local version with this?

comment:20 Changed 10 days ago by stdedos

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 r25205 GTK_Keyboard_Test.exe is broken, I used r24039)

So, here is the visualization roughly (Screenshot from the Windows client, including the shadowed Keyboard State Tool):

Last edited 10 days ago by stdedos (previous) (diff)

Changed 10 days ago by stdedos

comment:21 Changed 10 days ago by 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.zip is there now.

comment:22 in reply to:  21 Changed 10 days ago by stdedos

Replying to 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.zip is there now.

<3 It appears to be so much more convenient (and contained).

Same cx_Freeze error :/

comment:23 Changed 9 days ago by Antoine Martin

Same cx_Freeze error :/

Same as?
There is no mention of a cx_Freeze error in this ticket.

comment:24 in reply to:  23 Changed 9 days ago by stdedos

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 r25205)

I found also this one, but I think it's the same as the above one:

Last edited 7 days ago by stdedos (previous) (diff)

comment:25 Changed 8 days ago by stdedos

Still happening in r25314

comment:26 Changed 7 days ago by Antoine Martin

Owner: changed from stdedos to Antoine Martin
Status: newassigned

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.

comment:27 Changed 7 days ago by stdedos

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)

Changed 7 days ago by stdedos

comment:28 Changed 7 days ago by 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.

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.

comment:29 in reply to:  28 Changed 7 days ago by stdedos

Replying to 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 :/ weird

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.

Does this work for Windows too?

comment:30 Changed 7 days ago by stdedos

And the Windows side:

Xpra-Python3-x86_64_4.0-r25314\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:


but still the keys are the same weird keys

Last edited 7 days ago by stdedos (previous) (diff)

Changed 7 days ago by stdedos

Note: See TracTickets for help on using tickets.