From antoine at nagafix.co.uk Tue Dec 1 04:42:55 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 1 Dec 2020 11:42:55 +0700 Subject: [winswitch] xpra macOS support In-Reply-To: References: <921e1820-6e01-49e8-1781-3b133f9f2e03@umass.edu> Message-ID: <90e827a7-f5c0-93bd-4be3-a6c9335acd66@nagafix.co.uk> (..) > I did a clean install of Big Sur on a different system and was able to > access that > from a Windows 10 system - both systems are on the ethernet network where I > work. To get a working connection to the Big Sur system, I started the > xpra GUI > on the Big Sur system and manually started the xpra shadow server using the > "Shadow" button in the GUI, i.e. I haven't been able to establish a > connection to the > Big Sur system by initiating the connection from the Windows 10 system when > the Shadow server isn't already running on the Big Sur system. Right. There is currently no way to initiate a new shadow session on a windows or macos system through the GUI. This used to be possible using the command line: xpra shadow ssh://HOST/ That was using a macos agent, so you wouldn't need to be logged in. But they've changed something, so this no longer works. (I'm not sure how / if this can be fixed with newer versions of macos) > If you weren't aware of this, the first time the Shadow server is > started on a > Big Sur system, macOS prompts you with > > > ???? "sh" would like to record this computer's screen. > > ???? Grant access to this application in Security & Privacy > ???? preferences, located in System Preferences. > > > If you click the "Open System Preferences" button, an "sh" item is added to > "Security & Privacy | Privacy | Screen Recording", but if you don't > place a check > mark in the box to the left of "sh" in "Screen Recording", the effect of > clicking > the mouse buttons or pressing keys on keyboard, on the system you're > connnecting from, isn't displayed on the system you're connnecting from. Ah, that explains what I've been seeing when I last checked. (maybe I missed the prompt?) The name will eventually be changed from "sh" to a more useful and recognizable name if I ever try again to get the app notarized. (as Apple is unable to sign shell scripts) But this costs a yearly fee and is quite tedious, so this may take a while. > For example, if I position the mouse cursor of my Windows 10 system on the > Apple menu in the xpra window for the Big Sur system and left click, the > Apple menu opens on the Big Sur system but that activity isn't displayed > in the xpra window on the Windows 10 system. The keyboard doesn't seem > to work at all until the box to the left of "sh" is checked in "Screen > Recording". Thanks, for the details, this will help others. Cheers, Antoine From antoine at nagafix.co.uk Tue Dec 1 05:29:24 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 1 Dec 2020 12:29:24 +0700 Subject: [winswitch] Random connection drops in browser client In-Reply-To: References: Message-ID: <8e515f01-f2e5-7362-d9ef-4d9df51a4fbd@nagafix.co.uk> On 01/12/2020 06:23, Michael Cronenworth via shifter-users wrote: > Hi, > > I have had an issue with Xpra dropping and reconnecting sessions while > using applications inside the web browser client. I have experienced > this for several months and logs do not show a reason. Currently I'm > using Xpra 4.0.5. Does this also occur if you connect a regular python client to the same session? > I can leave a session open for hours without reconnect attempts if I > leave an application open and idle so I do not feel this is a network > connectivity issue. It's only randomly reconnecting after clicking > around applications, such as Firefox, inside a session. The randomness > frequency is anywhere from once per 5 minutes to a few times per minute. > It is not isolated to a single application. > > Server side logs show the client disconnected and then reconnected. No > warnings or other errors. Can you try to run your server with --debug=network and post the last few messages just before the client disconnection message? > Client side browser logs show: > websocket closed: undefined reason: null, reconnect: true, reconnect > attempt: 0 That's quite odd. The "websocket closed" event can only come from 3 places: * the server sending a "close" message (which would include a reason) * a protocol error in the HTML5 client (also includes a message) * the browser tears it down unceremoniously Only the last one would not include a "reason" message. Applying this patch will now include more details: http://xpra.org/trac/changeset/28048/xpra You can either apply it by hand or use the copy found here: http://xpra.org/html5/connect.html Other things worth trying: * use a tunnel to ensure that the websocket traffic isn't modified * use wireshark to inspect the last few packets before the connection drops (you should be able to see which end is closing first) > connection-list > ... tries to reconnect to server ... > (web browser shows session for a second) > connection-established > update encodings: (encodings listed...) > ping timeout - reconnecting > ... tries to reconnect to server ... > (this can cycle once, or a half-dozen times in a row, until finally....) > connection-established > update encodings: (encodings listed...) > server connection is OK > > The session is then "stable" until the next reconnection episode. > > Any ideas as to the cause? I'm afraid not. Please try the steps above, and if that does not help, file a ticket. Cheers, Antoine > > Thanks, > Michael From varvello at yahoo.com Wed Dec 2 14:36:01 2020 From: varvello at yahoo.com (Davide Varvello) Date: Wed, 2 Dec 2020 14:36:01 +0000 (UTC) Subject: [winswitch] Winswitch on Ubuntu 20.04 Focal Fossa References: <1686070291.2290393.1606919761816.ref@mail.yahoo.com> Message-ID: <1686070291.2290393.1606919761816@mail.yahoo.com> Hi Antoine,I'd like to run winswitch client on Ubuntu focal fossa, I installed Xpra but I can't find winswitch, also "apt-get install winswitch" gives me: unable to locate package.Can you help me, please?CheersDavide From antoine at nagafix.co.uk Wed Dec 2 15:12:44 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 2 Dec 2020 22:12:44 +0700 Subject: [winswitch] Winswitch on Ubuntu 20.04 Focal Fossa In-Reply-To: <1686070291.2290393.1606919761816@mail.yahoo.com> References: <1686070291.2290393.1606919761816.ref@mail.yahoo.com> <1686070291.2290393.1606919761816@mail.yahoo.com> Message-ID: <8cdc9ed7-450e-a45f-77e4-5a33df6982b5@nagafix.co.uk> On 02/12/2020 21:36, Davide Varvello via shifter-users wrote: > Hi Antoine,I'd like to run winswitch client on Ubuntu focal fossa, I installed Xpra but I can't find winswitch, also "apt-get install winswitch" gives me: unable to locate package.Can you help me, please?CheersDavide winswitch was never ported to Python3 and now that most distributions have dropped python2, it is effectively abandoned, sorry. Cheers, Antoine From antoine at nagafix.co.uk Mon Dec 7 13:02:43 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 7 Dec 2020 20:02:43 +0700 Subject: [winswitch] migrating away from trac and svn Message-ID: Hi, It has become necessary to move the bug tracker and wiki away from trac. The current plan is to transition to github and gitlab by the end of the year. If you have any opinions or suggestions on how / why this should be done, feel free to respond to this thread or on this ticket: https://xpra.org/trac/ticket/2967 Thanks, Antoine From mike at cchtml.com Tue Dec 8 16:24:43 2020 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 8 Dec 2020 10:24:43 -0600 Subject: [winswitch] Random connection drops in browser client In-Reply-To: <8e515f01-f2e5-7362-d9ef-4d9df51a4fbd@nagafix.co.uk> References: <8e515f01-f2e5-7362-d9ef-4d9df51a4fbd@nagafix.co.uk> Message-ID: On 11/30/20 11:29 PM, Antoine Martin via shifter-users wrote: > Does this also occur if you connect a regular python client to the same > session? I have not tried it yet, so I installed the 4.0.5 Windows client. After a few minutes the thick client also disconnects. In this instance I was using Firefox and randomly left and right clicking on the redhat.com web page and eventually it disconnected the client. The server log shows similar messages as the HTML5 client. > Can you try to run your server with --debug=network and post the last > few messages just before the client disconnection message? HTML 5 client (wss connection): With network debugging enabled I am seeing the client request a disconnect. Then the server times out on the reconnect and a second reconnect establishes. ... 2020-12-08 07:37:35,978 process ui packet pointer-position 2020-12-08 07:37:35,978 processing packet pointer-position 2020-12-08 07:37:35,978 process ui packet pointer-position 2020-12-08 07:37:36,004 packet type send alias not found for 'draw' 2020-12-08 07:37:36,007 processing packet disconnect 2020-12-08 07:37:36,007 process default packet disconnect 2020-12-08 07:37:36,007 client has requested disconnection: server shutdown (client connection lost) ... tries to reconnect, but I see a timeout 2012-12-08 07:37:39,339 peek: elapsed=751, timeout=1000 2012-12-08 07:37:39,559 peek: elapsed=1001, timeout=1000 2012-12-08 07:37:39,559 socket unix-domain socket:/run/user//xpra/-0 peek: got 0 bytes ... 2012-12-08 07:37:39,565 process_connection_list(Protocol(None), ['connection-lost']) 2012-12-08 07:37:39,565 cleanup_protocol(Protocol(None)) 2012-12-08 07:37:39,589 peek: elapsed=1001, timeout=1000 ... tries to reconnect, and succeeds Python client (wss connection): The logs say the client requested a disconnect. The client doesn't auto-reconnect like the HTML5 client does so the log ends. ... 2020-12-08 08:45:21,060 processing packet pointer-position 2020-12-08 08:45:21,060 process ui packet pointer-position 2020-12-08 08:45:21,068 processing packet pointer-position 2020-12-08 08:45:21,068 process ui packet pointer-position 2020-12-08 08:45:21,085 processing packet disconnect 2020-12-08 08:45:21,085 processing default packet disconnect 2020-12-08 08:45:21,085 client has requested disconnection: server shutdown (client connection lost) ... > That's quite odd. The "websocket closed" event can only come from 3 places: > * the server sending a "close" message (which would include a reason) > * a protocol error in the HTML5 client (also includes a message) > * the browser tears it down unceremoniously > > Only the last one would not include a "reason" message. > Applying this patch will now include more details: > http://xpra.org/trac/changeset/28048/xpra > You can either apply it by hand or use the copy found here: > http://xpra.org/html5/connect.html > > Other things worth trying: > * use a tunnel to ensure that the websocket traffic isn't modified > * use wireshark to inspect the last few packets before the connection > drops (you should be able to see which end is closing first) > I have not tried this patch yet, or a packet capture, but I will if you think it is worth pursuing. Thank you, Michael From antoine at nagafix.co.uk Wed Dec 9 05:56:36 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 9 Dec 2020 12:56:36 +0700 Subject: [winswitch] Random connection drops in browser client In-Reply-To: References: <8e515f01-f2e5-7362-d9ef-4d9df51a4fbd@nagafix.co.uk> Message-ID: <4dad11c0-f8bf-af53-223c-8d02367f65fd@nagafix.co.uk> On 08/12/2020 23:24, Michael Cronenworth via shifter-users wrote: > On 11/30/20 11:29 PM, Antoine Martin via shifter-users wrote: >> Does this also occur if you connect a regular python client to the same >> session? > > I have not tried it yet, so I installed the 4.0.5 Windows client. After > a few minutes the thick client also disconnects. In this instance I was > using Firefox and randomly left and right clicking on the redhat.com web > page and eventually it disconnected the client. The server log shows > similar messages as the HTML5 client. > >> Can you try to run your server with --debug=network and post the last >> few messages just before the client disconnection message? > > HTML 5 client (wss connection): > With network debugging enabled I am seeing the client request a > disconnect. Then the server times out on the reconnect and a second > reconnect establishes. > (..) > 2020-12-08 07:37:36,007 client has requested disconnection: server > shutdown (client connection lost) (..) > Python client (wss connection): > The logs say the client requested a disconnect. The client doesn't > auto-reconnect like the HTML5 client does so the log ends. (..) > 2020-12-08 08:45:21,085 client has requested disconnection: server > shutdown (client connection lost) I believe that the "client connection lost" messages shown here can only come from a proxy server. Are you running via a proxy server? And if so, have you tried without? The proxy server log may well have the details you need (run "-d proxy" to get more verbose messages). And perhaps your server process uses "--exit-with-client" and it then terminates. My guess is that something external is severing the connection (the OS or a firewall) and then what happens in the xpra server is expected. We have sessions running for days at a time, and those connections don't drop. Cheers, Antoine > ... > >> That's quite odd. The "websocket closed" event can only come from 3 >> places: >> * the server sending a "close" message (which would include a reason) >> * a protocol error in the HTML5 client (also includes a message) >> * the browser tears it down unceremoniously >> >> Only the last one would not include a "reason" message. >> Applying this patch will now include more details: >> http://xpra.org/trac/changeset/28048/xpra >> You can either apply it by hand or use the copy found here: >> http://xpra.org/html5/connect.html >> >> Other things worth trying: >> * use a tunnel to ensure that the websocket traffic isn't modified >> * use wireshark to inspect the last few packets before the connection >> drops (you should be able to see which end is closing first) >> > > I have not tried this patch yet, or a packet capture, but I will if you > think it is worth pursuing. > > Thank you, > Michael > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From mike at cchtml.com Wed Dec 9 22:36:11 2020 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 9 Dec 2020 16:36:11 -0600 Subject: [winswitch] Random connection drops in browser client In-Reply-To: <4dad11c0-f8bf-af53-223c-8d02367f65fd@nagafix.co.uk> References: <8e515f01-f2e5-7362-d9ef-4d9df51a4fbd@nagafix.co.uk> <4dad11c0-f8bf-af53-223c-8d02367f65fd@nagafix.co.uk> Message-ID: <176b54b9-4d52-dfa1-a30a-e664eebdeb4f@cchtml.com> On 12/8/20 11:56 PM, Antoine Martin via shifter-users wrote: > I believe that the "client connection lost" messages shown here can only > come from a proxy server. Are you running via a proxy server? > And if so, have you tried without? The proxy server log may well have > the details you need (run "-d proxy" to get more verbose messages). > > And perhaps your server process uses "--exit-with-client" and it then > terminates. > My guess is that something external is severing the connection (the OS > or a firewall) and then what happens in the xpra server is expected. > > We have sessions running for days at a time, and those connections don't > drop. Yes, this is using the proxy server offered with the 'xpra.socket' systemd unit provided by your xpra RPM packages. I'll try to capture logs from the proxy server. I understand you have sessions running for days. I can leave an idle session with idle appliations open for days. The issue is only when applications are in use. I can leave active SSH sessions open for days. I haven't taken packet captures yet, but I doubt this is an OS or firewall issue. From luca.manganelli at comune.trento.it Thu Dec 17 08:26:19 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 17 Dec 2020 09:26:19 +0100 Subject: [winswitch] How to increment start timeout? Message-ID: Hello, i'm using xpra to launch a terminal. Unfortunately, it takes too much time and so the xpra terminates the connection, and I had to do it again (only one more time). Is there any way to make the timeout longer? From antoine at nagafix.co.uk Thu Dec 17 08:32:32 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 17 Dec 2020 15:32:32 +0700 Subject: [winswitch] How to increment start timeout? In-Reply-To: References: Message-ID: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> On 17/12/2020 15:26, Luca Manganelli via shifter-users wrote: > Hello, > > i'm using xpra to launch a terminal. What is the exact command you are using? And what version are you using, on what OS? > Unfortunately, it takes too much time and so the xpra terminates the > connection, and I had to do it again (only one more time). > Is there any way to make the timeout longer? Generally speaking, you should not need to modify any timeouts, it's likely that there's a problem if you do. The xpra server should start quickly enough that you never hit any timeouts. Cheers, Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From luca.manganelli at comune.trento.it Thu Dec 17 08:34:42 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 17 Dec 2020 09:34:42 +0100 Subject: [winswitch] How to increment start timeout? In-Reply-To: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> References: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> Message-ID: Il giorno gio 17 dic 2020 alle ore 09:32 Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> ha scritto: > What is the exact command you are using? XPRA_PULSE_SINK_DEVICE_NAME='Audio interno Stereo analogico' xpra start ssh://user at 192.168.1.10/ --start-child=gnome-terminal --dpi=120 > And what version are you using, on what OS? xpra 4.0.5, last version Fedora 33 From antoine at nagafix.co.uk Thu Dec 17 08:39:50 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 17 Dec 2020 15:39:50 +0700 Subject: [winswitch] How to increment start timeout? In-Reply-To: References: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> Message-ID: <9e6b1cbd-f816-fd8a-1ab5-65916e82276f@nagafix.co.uk> On 17/12/2020 15:34, Luca Manganelli wrote: > Il giorno gio 17 dic 2020 alle ore 09:32 Antoine Martin via > shifter-users > ha scritto: >> What is the exact command you are using? > > XPRA_PULSE_SINK_DEVICE_NAME='Audio interno Stereo analogico' xpra start > ssh://user at 192.168.1.10/ > --start-child=gnome-terminal --dpi=120 > >> And what version are you using, on what OS? > > xpra 4.0.5, last version > Fedora 33 OK, thanks. This should start fast enough on any decent hardware. Can you post your server log so we can see where it is spending all that time? Look for /run/user/$UID/xpra/$DISPLAY.log Cheers, Antoine From luca.manganelli at comune.trento.it Thu Dec 17 08:54:05 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 17 Dec 2020 09:54:05 +0100 Subject: [winswitch] How to increment start timeout? In-Reply-To: <9e6b1cbd-f816-fd8a-1ab5-65916e82276f@nagafix.co.uk> References: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> <9e6b1cbd-f816-fd8a-1ab5-65916e82276f@nagafix.co.uk> Message-ID: l giorno gio 17 dic 2020 alle ore 09:39 Antoine Martin < antoine at nagafix.co.uk> ha scritto: > Look for /run/user/$UID/xpra/$DISPLAY.log Warning: the 'start-child' option is used, but 'exit-with-children' is not enabled, use 'start' instead 2020-12-17 09:52:04,760 cannot access python uinput module: 2020-12-17 09:52:04,760 No module named 'uinput' X.Org X Server 1.20.10 X Protocol Version 11, Revision 0 Build Operating System: 5.7.11-200.fc32.x86_64 Current Operating System: Linux 11C82 5.9.13-200.fc33.x86_64 #1 SMP Tue Dec 8 15:42:52 UTC 2020 x86_64 Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.9.13-200.fc33.x86_64 root=/dev/mapper/fedora_11c87-root ro resume=/dev/mapper/fedora _11c87-swap rd.lvm.lv=fedora_11c87/root rd.lvm.lv=fedora_11c87/swap rhgb quiet rd.driver.blacklist=nouveau nouveau.modeset=0 rd.plymouth= 0 plymouth.enable=0 Build Date: 02 December 2020 12:00:00AM Build ID: xorg-x11-server 1.20.10-1.fc33 Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (++) Log file: "/run/user/1000/xpra/Xorg.S11616.log", Time: Thu Dec 17 09:52:04 2020 (++) Using config file: "/etc/xpra/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" 2020-12-17 09:52:12,137 created unix domain socket '/run/user/1000/xpra/11C82-0' 2020-12-17 09:52:12,137 cannot create group socket '/run/xpra/11C82-0' 2020-12-17 09:52:12,137 [Errno 13] Permission denied 2020-12-17 09:52:13,010 pointer device emulation using XTest 2020-12-17 09:52:13,424 serving html content from '/usr/share/xpra/www' 2020-12-17 09:52:13,620 Warning: failed to load the mdns publisher 2020-12-17 09:52:13,621 No module named 'avahi' 2020-12-17 09:52:13,621 either install the 'python-avahi' module 2020-12-17 09:52:13,621 or use the 'mdns=no' option 2020-12-17 09:52:13,712 D-Bus notification forwarding is available 2020-12-17 09:52:13,738 pulseaudio server started with pid 11695 2020-12-17 09:52:13,739 private server socket path: 2020-12-17 09:52:13,739 '/run/user/1000/xpra/pulse-0/pulse/native' 2020-12-17 09:52:14,983 GStreamer version 1.18.2 for Python 3.9.0 64-bit (Xpra:11622): Gtk-CRITICAL **: 09:52:15.628: gtk_widget_realize: assertion 'widget->priv->anchored || GTK_IS_INVISIBLE (widget)' failed 2020-12-17 09:52:15,720 Warning: webcam forwarding is disabled 2020-12-17 09:52:15,720 the virtual video directory '/sys/devices/virtual/video4linux' was not found 2020-12-17 09:52:15,720 make sure that the 'v4l2loopback' kernel module is installed and loaded 2020-12-17 09:52:15,720 found 0 virtual video devices for webcam forwarding 2020-12-17 09:52:15,779 printer forwarding enabled using postscript and pdf 2020-12-17 09:52:15,805 started command 'gnome-terminal' with pid 11755 2020-12-17 09:52:16,001 xpra is ready. 2020-12-17 09:52:16,011 xpra GTK3 X11 version 4.0.5-r27999 64-bit 2020-12-17 09:52:16,017 watching for applications menu changes in: 2020-12-17 09:52:16,018 '/var/lib/flatpak/exports/share/applications' 2020-12-17 09:52:16,018 '/usr/local/share/applications' 2020-12-17 09:52:16,018 '/usr/share/applications' 2020-12-17 09:52:16,018 '/var/lib/snapd/desktop/applications' 2020-12-17 09:52:16,680 New unix-domain connection received 2020-12-17 09:52:16,680 on '/run/user/1000/xpra/11C82-0' 2020-12-17 09:52:16,935 New unix-domain connection received 2020-12-17 09:52:16,935 on '/run/user/1000/xpra/11C82-0' 2020-12-17 09:52:16,940 Handshake complete; enabling connection 2020-12-17 09:52:17,082 New unix-domain connection received 2020-12-17 09:52:17,082 on '/run/user/1000/xpra/11C82-0' 2020-12-17 09:52:17,398 uid=1000 (manganelll), gid=1000 (manganelll) 2020-12-17 09:52:17,398 running with pid 11622 on Linux Fedora 33 ThirtyThree 2020-12-17 09:52:24,559 Python/GTK3 Linux Neon 20.04 focal x11 client version 4.0.5-r27999 64-bit 2020-12-17 09:52:24,559 OpenGL is enabled with Mesa Intel(R) HD Graphics 530 (SKL GT2) 2020-12-17 09:52:24,559 connected from 'hp800' as 'manganelll' - 'luca' 2020-12-17 09:52:24,668 connected to X11 display :0 with 24 bit colors 2020-12-17 09:52:24,887 setting key repeat rate from client: 600ms delay / 40ms interval 2020-12-17 09:52:24,892 setting keymap: The XKEYBOARD keymap compiler (xkbcomp) reports: > Internal error: Could not resolve keysym XF86FullScreen Errors from xkbcomp are not fatal to the X server 2020-12-17 09:52:25,022 setting keyboard layout to 'it' The XKEYBOARD keymap compiler (xkbcomp) reports: > Internal error: Could not resolve keysym XF86FullScreen Errors from xkbcomp are not fatal to the X server 2020-12-17 09:52:25,136 client root window size is 1920x1080 with 1 display: 2020-12-17 09:52:25,136 :0.0 (506x285 mm - DPI: 96x96) workarea: 1920x1044 2020-12-17 09:52:25,137 PHL DP-1 (527x296 mm - DPI: 92x92) 2020-12-17 09:52:25,206 server virtual display now set to 1920x1080 From antoine at nagafix.co.uk Thu Dec 17 12:32:27 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 17 Dec 2020 19:32:27 +0700 Subject: [winswitch] How to increment start timeout? In-Reply-To: References: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> <9e6b1cbd-f816-fd8a-1ab5-65916e82276f@nagafix.co.uk> Message-ID: > 2020-12-17 09:52:04,760 cannot access python uinput module: (..) 8 seconds to start the X11 server, slow. You may want to switch to Xvfb and see if that starts faster for you. See /etc/xpra/conf.d/55_server_x11.conf on the server. > 2020-12-17 09:52:12,137 cannot create group socket '/run/xpra/11C82-0' (..) Then 4 more seconds for xpra itself - which isn't great but acceptable: > 2020-12-17 09:52:16,001 xpra is ready. (..) > 2020-12-17 09:52:16,940 Handshake complete; enabling connection (..) > 2020-12-17 09:52:17,082 New unix-domain connection received > 2020-12-17 09:52:17,082 ?on '/run/user/1000/xpra/11C82-0' > 2020-12-17 09:52:17,398 ?uid=1000 (manganelll), gid=1000 (manganelll) > 2020-12-17 09:52:17,398 ?running with pid 11622 on Linux Fedora 33 > ThirtyThree Though it takes another 7 seconds before the client is ready. Not quite sure what went on during that time - it could be related to this bug: https://xpra.org/trac/ticket/2978#comment:14 You may want to try the latest beta, apply the environment variable workaround on the server, or use "--start-new-commands=no". > 2020-12-17 09:52:24,559 Python/GTK3 Linux Neon 20.04 focal x11 client > version 4.0.5-r27999 64-bit(..) So that took 20 seconds from start to finish - which is on the slow side, but this did not fail. (the timeout is longer than that IIRC) Do you have a log of when it does fail and timeout? FWIW: on my somewhat old system, it takes 6 seconds to get a window up: $ xpra start ssh://localhost/ --start=xterm 2020-12-17 19:27:20,296 Xpra GTK3 client version 4.1-r28171M 64-bit (..) 2020-12-17 19:27:26,177 Xpra GTK3 X11 server version 4.1-r28171 64-bit 2020-12-17 19:27:26,177 running on Linux Fedora 31 ThirtyOne Cheers, Antoine From luca.manganelli at comune.trento.it Fri Dec 18 09:05:03 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Fri, 18 Dec 2020 10:05:03 +0100 Subject: [winswitch] How to increment start timeout? In-Reply-To: References: <82af131b-ae15-f39e-5d77-c50e8a83b18f@nagafix.co.uk> <9e6b1cbd-f816-fd8a-1ab5-65916e82276f@nagafix.co.uk> Message-ID: Ok, it seems that using Xvfb solved the problem. From totaam at xpra.org Thu Dec 31 13:09:47 2020 From: totaam at xpra.org (Antoine Martin) Date: Thu, 31 Dec 2020 20:09:47 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.0.6: many fixes, none critical Message-ID: Hi, This release fixes a large number of bugs but none of them are critical, so there is no urgency to update if you were not affected. That said, quite a few of the issues which have been fixed greatly enhance the user experience. The "~/.xpra" path has been reluctantly re-added to the list of socket directories on Posix systems, this is to workaround a number of hard to diagnose issues that users regularly encounter when XDG_RUNTIME_DIR is not already created correctly or gets destroyed later on, ie: when running xpra in containers or via ssh / su logins. The PDFium printing library has finally been updated in the MS Windows builds. The previous version provided by the mingw64 packages was well out of date and likely included some security vulnerabilities. Here's a short summary: * performance issues: jittery links, server startup speed * screen repaint fixes for mmap and wayland * proxy server bugs: leaks, zombies, etc * network fixes: missing packet compression, ssh mode errors * keyboard: CapsLock with shadow servers, sub-layout detection on MS Windows * clipboard: wayland fix, errors on MS Windows * file-transfers: fix silent printing errors, failures with small files or unicode file names * build and packaging issues: missing codecs, dependencies, etc * misc: tray icons, printing, python 3.9 compatibility, FIPS compatibility, logging tweaks Full release notes: * fix screen refresh performance issues, especially on jittery links * fix proxy instance control socket errors and process leak * fix slow subcommands due to unnecessary calls to ldconfig on Linux * fix server asynchronous packets getting delayed * fix 'xpra _proxy' zombies getting left behind (ssh mode) * fix failures to enable packet compression * fix connection errors when a non interactive client is already connected * fix ssh connection errors with proxycommand or proxyhost port numbers * fix timeouts with paramiko ssh client * fix ssh string escaping with MS Windows clients * fix client rejecting printing requests * fix duplicate / untimely audio-stop control packets with HTML5 client * fix console errors with Internet Explorer * fix capslock regression on MacOS and MSWindows shadow servers * fix errors accessing window handles on MS Windows (size hints, opengl, etc) * fix spurious refresh packets with mmap * fix mmap not used with some non-video areas * fix missing avcodec decoder with MS Windows builds * fix missing webp Pillow decoder with MS Windows builds * fix missing tray icons regression on MS Windows (introduced in 4.0.5) * fix warning message format when running MS Windows under VirtualBox * fix keyboard sub-layout detection with MS Windows clients * fix clipboard cleanup errors on MS Windows * fix clipboard with Wayland clients * fix window repaint with Wayland clients * fix printing diagnostic script * fix Python 3.9 compatibility * fix sysconfig path in systemd service file for non-RedHat systems * fix xdg-open override script error handling * fix file-transfer failures with small files * fix file-transfers with non-ascii filenames * fix FIPS compatibility (no md5) * better file transfer message format * honour XPRA_XDG_EXPORT_ICONS=0 env var in all cases * hide passwords from authentication debug logging * updated DEB packaging for Ubuntu Focal, Groovy and Debian Bullseye * updated DEB dependencies to not recommend installing Gnome * use an up-to-date PDFium library on MS Windows * make it possible to specify the socket type with systemd socket activation * re-add "~/.xpra" as socket-dir * typo in man page The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine