Xpra trac archive

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

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, ...:

... but the steps seem too much:

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

... they sound irrelevant:

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

(#2299 was found during this ticket)

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


Fri, 17 May 2019 08:57:20 GMT - stdedos: attachment set

Fri, 17 May 2019 08:59:07 GMT - stdedos: attachment set

Sun, 26 May 2019 10:30:12 GMT - Antoine Martin: owner changed

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.

Sun, 26 May 2019 11:35:48 GMT - 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

Sun, 26 May 2019 11:42:43 GMT - Antoine Martin:

Is it possible to do that?

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

Tue, 18 Jun 2019 09:41:57 GMT - 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'.

Tue, 18 Jun 2019 10:21:10 GMT - stdedos: owner changed

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

Tue, 18 Jun 2019 10:21:25 GMT - stdedos: attachment set

Tue, 18 Jun 2019 10:22:59 GMT - stdedos: attachment set

Tue, 18 Jun 2019 10:26:26 GMT - Antoine Martin: owner changed

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.

Tue, 18 Jun 2019 10:34:06 GMT - 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.

Tue, 18 Jun 2019 10:39:10 GMT - 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.

Tue, 18 Jun 2019 11:18:59 GMT - 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.

Tue, 18 Jun 2019 12:02:35 GMT - 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)

Tue, 18 Jun 2019 12:41:40 GMT - 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'>

Fri, 20 Sep 2019 07:19:33 GMT - Antoine Martin: owner, status, milestone changed

Fri, 06 Dec 2019 01:05:39 GMT - 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.

Thu, 06 Feb 2020 03:20:26 GMT - Antoine Martin: owner, status changed

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

If not, then #2574 may help too.

Thu, 13 Feb 2020 09:05:06 GMT - 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.

Thu, 13 Feb 2020 09:05:25 GMT - stdedos: attachment set

Fri, 14 Feb 2020 12:19:02 GMT - 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

Fri, 14 Feb 2020 12:51:21 GMT - 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:

Can you add that on that window too?

The only change that is not in 3.0.6 is r25174 + r25175. This may eventually land in 3.1.x

Sat, 15 Feb 2020 08:44:44 GMT - Antoine Martin:

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

Done in r25236.

Sat, 15 Feb 2020 09:50:30 GMT - stdedos:

Backport to 3.0.x?

Or can I just update my local version with this?

Tue, 18 Feb 2020 10:36:53 GMT - 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):

Tue, 18 Feb 2020 10:37:09 GMT - stdedos: attachment set

Tue, 18 Feb 2020 12:12:45 GMT - 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.

Tue, 18 Feb 2020 17:48:22 GMT - 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 :/

Wed, 19 Feb 2020 04:11:25 GMT - Antoine Martin:

Same cx_Freeze error :/

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

Wed, 19 Feb 2020 06:42:36 GMT - 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:

Thu, 20 Feb 2020 19:00:49 GMT - stdedos:

Still happening in r25314

Fri, 21 Feb 2020 08:50:07 GMT - Antoine Martin: owner, status changed

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.

Fri, 21 Feb 2020 09:08:23 GMT - 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)

Fri, 21 Feb 2020 09:09:22 GMT - stdedos: attachment set

Fri, 21 Feb 2020 09:19:58 GMT - 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.

Fri, 21 Feb 2020 09:41:37 GMT - 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?

Fri, 21 Feb 2020 19:58:24 GMT - 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

Fri, 21 Feb 2020 20:02:09 GMT - stdedos: attachment set

Thu, 05 Mar 2020 18:07:44 GMT - Antoine Martin: owner, status changed

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.

Thu, 05 Mar 2020 19:12:07 GMT - stdedos:

I have no idea. I merely added the (modern) Greek language and keyboard, alongside English for my user. This is a multi-user machine provisioned in Finland, with Finnish / English keyboard.

Attaching with: 

"Xpra-Python3-x86_64_4.0-r25519\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 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 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+μ,./ :

Thu, 05 Mar 2020 19:12:40 GMT - stdedos: attachment set

Thu, 05 Mar 2020 19:12:51 GMT - stdedos: attachment set

Thu, 05 Mar 2020 19:13:00 GMT - stdedos: attachment set

Fri, 06 Mar 2020 08:09:57 GMT - Antoine Martin: attachment set

greek keyboard layout

Fri, 06 Mar 2020 08:10:34 GMT - Antoine Martin: owner, status changed

For my own reference, I believe the keyboard layout used is this one: greek keyboard layout

Fri, 06 Mar 2020 10:15:49 GMT - stdedos:

This is what it would look like physically:

Fri, 06 Mar 2020 10:15:58 GMT - stdedos: attachment set

Fri, 06 Mar 2020 12:51:37 GMT - Antoine Martin: owner, status changed

I am very confident that this is fixed in r25529 so I've already backported the fix to the v3.0 branch in r25532. 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.

Fri, 06 Mar 2020 21:47:56 GMT - stdedos:

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:

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

Sat, 07 Mar 2020 04:08:28 GMT - Antoine Martin:

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.

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

Sort of. But that has to be done at connection setup time because:

You can't. Changing layout takes a long time and triggers all sorts of unwanted system events.

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.

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.

Tue, 10 Mar 2020 12:54:49 GMT - stdedos:

FINALLY we can close this. It works:

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

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

Tue, 10 Mar 2020 12:55:21 GMT - stdedos: attachment set

Wed, 11 Mar 2020 03:57:06 GMT - Antoine Martin: status changed; resolution set

This caused a regression: ticket:2632#comment:8

Mon, 16 Mar 2020 15:48:31 GMT - Antoine Martin:

And another regression: #2648.

Thu, 02 Apr 2020 04:29:06 GMT - Antoine Martin:

And another regression: #2702

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

This ticket is similar to #1465.

Sat, 23 Jan 2021 05:47:37 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2301