From wssddc at wssddc.com Tue Oct 1 05:46:10 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Tue, 1 Oct 2019 00:46:10 -0400 Subject: [winswitch] Xpra 3.0 Windows very slow ssh login Message-ID: Running xpra 3.0.0.0 on 64-bit Windows 7, connecting to 64-bit Fedora 29, the ssh login prompt hangs up for ~15 seconds, then responds to past typing and works.? The whole system is unresponsive during the hang; my onscreen clock even stops ticking.? Reverting to 3.0-r23707 (the last version I downloaded) fixes it.? Failing version was downloaded from https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe.? This is on my wired local home network with nothing much else happening.? A wireless Windows 10 laptop behaves similarly. On the Linux side, dnf says I'm up-to-date with winswitch-beta in my repo list.? Installed xpra stuff: # rpm -qa|grep xpra|sort ffmpeg-xpra-4.2.1-1.fc29.x86_64 python2-lz4-2.1.6-1.xpra1.fc29.x86_64 python2-xpra-3.0-0.20190928r24021M.fc29.x86_64 python2-xpra-audio-3.0-0.20190928r24021M.fc29.x86_64 python2-xpra-client-3.0-0.20190928r24021M.fc29.x86_64 python2-xpra-server-3.0-0.20190928r24021M.fc29.x86_64 python3-lz4-2.1.6-1.xpra1.fc29.x86_64 python3-xpra-3.0-0.20190928r24021M.fc29.x86_64 python3-xpra-audio-3.0-0.20190928r24021M.fc29.x86_64 python3-xpra-client-3.0-0.20190928r24021M.fc29.x86_64 python3-xpra-server-3.0-0.20190928r24021M.fc29.x86_64 x264-xpra-20190929-1.fc29.x86_64 xorg-x11-drv-dummy-0.3.8-1.xpra1.fc29.x86_64 xpra-3.0-0.20190928r24021M.fc29.x86_64 xpra-common-3.0-0.20190928r24021M.fc29.noarch xpra-common-client-3.0-0.20190928r24021M.fc29.noarch xpra-common-server-3.0-0.20190928r24021M.fc29.noarch xpra-html5-3.0-0.20190928r24021M.fc29.noarch From antoine at nagafix.co.uk Tue Oct 1 07:08:43 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 1 Oct 2019 13:08:43 +0700 Subject: [winswitch] Xpra as screen recorder? In-Reply-To: References: Message-ID: <7d7fdbf9-3936-9006-b577-206fd6a11e2d@nagafix.co.uk> On 01/10/2019 05:10, Karl Semich via shifter-users wrote: > Hi, > > I've been thinking on how to make highly compact screen recordings and my > focus landed on xpra packet logs. Bear in mind that in some cases, the xpra packets may aggregate multiple screen updates into a bigger rectangle to reduce the processing and network traffic overhead. > Does anybody have any thoughts on possibly using xpra to record/replay > sessions? Has this been attempted before / does it seem a reasonable idea > to you? The code is quite well separated between the network and the higher layers so you should be able to feed the packets to a custom client class. There's bound to be some more thorny issues I can't think of, but nothing insurmountable. Please create a ticket for this. I'm sure this could be useful, to reproduce bugs for example. Cheers, Antoine > > Thanks so much, > Karl Semich > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Oct 1 07:18:28 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 1 Oct 2019 13:18:28 +0700 Subject: [winswitch] Xpra 3.0 Windows very slow ssh login In-Reply-To: References: Message-ID: On 01/10/2019 11:46, Bob Babcock via shifter-users wrote: > Running xpra 3.0.0.0 on 64-bit Windows 7, connecting to 64-bit Fedora > 29, the ssh login prompt hangs up for ~15 seconds, then responds to past > typing and works. I'm seeing a slight delay as we launch the subprocess handling the password prompt, but nowhere near 15 seconds, more like 2 or 3 seconds. I just assumed that the system I was testing on was a bit slow. > The whole system is unresponsive during the hang; my > onscreen clock even stops ticking. No user application should be able to do that.. could be triggering some sort of Windows OS bug. >? Reverting to 3.0-r23707 (the last > version I downloaded) fixes it.? Failing version was downloaded from > https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe.? This is on my > wired local home network with nothing much else happening.? A wireless > Windows 10 laptop behaves similarly. Thanks. I'll take a look ASAP. In the meantime, you can switch to plink instead of the paramiko backend: xpra_cmd --ssh="plink.exe" attach ssh://username:password at host/ > > On the Linux side, dnf says I'm up-to-date with winswitch-beta in my > repo list. Installed xpra stuff: > > # rpm -qa|grep xpra|sort > ffmpeg-xpra-4.2.1-1.fc29.x86_64 > python2-lz4-2.1.6-1.xpra1.fc29.x86_64 > python2-xpra-3.0-0.20190928r24021M.fc29.x86_64 > python2-xpra-audio-3.0-0.20190928r24021M.fc29.x86_64 > python2-xpra-client-3.0-0.20190928r24021M.fc29.x86_64 > python2-xpra-server-3.0-0.20190928r24021M.fc29.x86_64 > python3-lz4-2.1.6-1.xpra1.fc29.x86_64 > python3-xpra-3.0-0.20190928r24021M.fc29.x86_64 > python3-xpra-audio-3.0-0.20190928r24021M.fc29.x86_64 > python3-xpra-client-3.0-0.20190928r24021M.fc29.x86_64 > python3-xpra-server-3.0-0.20190928r24021M.fc29.x86_64 > x264-xpra-20190929-1.fc29.x86_64 > xorg-x11-drv-dummy-0.3.8-1.xpra1.fc29.x86_64 > xpra-3.0-0.20190928r24021M.fc29.x86_64 > xpra-common-3.0-0.20190928r24021M.fc29.noarch > xpra-common-client-3.0-0.20190928r24021M.fc29.noarch > xpra-common-server-3.0-0.20190928r24021M.fc29.noarch > xpra-html5-3.0-0.20190928r24021M.fc29.noarch The stable repository actually has 3.0 proper, which is very slightly newer than this. You should always add both stable and beta repositories, as the beta one is only a supplemental one, which may or may not have packages in it. FYI: 4.0 builds will start landing in the beta area soon. Cheers, Antoine From wssddc at wssddc.com Wed Oct 2 06:31:10 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Wed, 2 Oct 2019 01:31:10 -0400 Subject: [winswitch] Xpra 3.0 Windows very slow ssh login In-Reply-To: References: Message-ID: <55ece208-bedb-438e-bcf3-d56f4b3dcc02@wssddc.com> Antoine Martin via shifter-users wrote: > In the meantime, you can switch to plink instead of the paramiko backend: Confirmed, on Windows 7 I see no hangup at the ssh login dialog when using plink and xpra 3.0.0.0. > The stable repository actually has 3.0 proper, which is very slightly newer > than this. > You should always add both stable and beta repositories, as the beta one is > only a supplemental one, which may or may not have packages in it. I'm not ready to experiment with version 4 yet, so I disabled the beta repository, uninstalled *xpra* and reinstalled.? That does indeed give a slightly newer 3.0.? As I recall, I added the beta repo a while back to fix some problem or conflict with updating.? I forget the details, but there's no problem today. Thanks. From totaam at xpra.org Sun Oct 6 20:15:35 2019 From: totaam at xpra.org (Antoine Martin) Date: Mon, 7 Oct 2019 02:15:35 +0700 Subject: [winswitch] ANNOUNCE: Xpra 1.0.14 LTS Message-ID: Hi, This latest update to the 1.0 LTS branch is likely to be the final one unless severe issues are found in the next year or so. There are no significant fixes here, most of the issues are either hard to hit or just not critical. The codec libraries have been updated to the latest versions available (on Linux only), matching what is used by the new 3.0 LTS branch. At this point there are no known reasons for sticking with this outdated 1.0 branch unless your servers are running an outdated distribution like CentOS / RHEL 6.x The new 3.0 LTS supersedes it. The MS Windows (XP 32-bit) and MacOS (10.5.x 32-bit) installers are provided for reference only, please bear in mind that those are using outdated libraries throughout and they are riddled with serious security issues, do not use these builds in production. Use the newer supported versions instead. Release notes: * fix html5 clipboard wrongly disabled * fix html5 handling of websocket frames with more than one packet * fix desktop-scaling normalization calculations * fix handling of unicode values for desktop names * fix file descriptor leak when running child commands * fix MS Windows tray icon backport * fix XShape serial not being ignored as it should * fix race condition with some clipboard control packets * fix unused method call for consistency * fix skip-pager window hint wrongly applied to skip-taskbar attribute * fix CUDA reset_state function * fix wrong flags shown on swscale debug output * fix resource leak in server connection tracking * fix missing network statistics * fix window model cleanup code * fix error in packet failure handler logging * fix some window control commands that trigger a refresh * fix server dbus service attribute accessor methods * fix network jitter injector * fix avahi mdns publisher test tool * fix error in the codec loader if the first codec attempted fails * fix mmap leak which can cause the client to stop painting * fix HTML5 client authentication issue when going through a proxy server * fix errors if md5 is not available: use sha1 * fix win32 system tray not responding to clicks after re-initialization * fix file descriptors not closed on exit * fix proxy instances emulation of glib repeating calls * fix unlikely (impossible?) error with virtual webcams * fix man page headers alignment * silence annoying atk warnings * silence ffmpeg build warnings with GCC 9 * avoid running invalid lpinfo commands * support newer nvidia encode shared libraries * prevent hash collisions in motion search * warn that Python optimized code will crash * avoid using jpeg for video edges * add missing exec-wrapper section to man page * remove support for broken python3 builds * packaging fixes for Ubuntu cosmic, appindicator * disable xvid and ffmpeg * disable avcodec decoder on MS Windows * avoid keyboard warnings * fix sdist The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From florian.feldhaus at gmail.com Fri Oct 11 16:04:42 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Fri, 11 Oct 2019 17:04:42 +0200 Subject: [winswitch] Update for Xpra running Wireshark in Docker container Message-ID: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> A while ago, I created a Docker image to run Wireshark via a Webbrowser. You can find the old mail thread here: https://shifter-users.devloop.org.narkive.com/x5ibNYzP/winswitch-xpra-running-wireshark-in-docker-container I completely forgot about this, but recently discovered that it seems to be really popular (over 200K downloads of the image to date) and I decided to update the image (and will ask people to donate to Wireshark and XPRA if they like the image). Mostly it is working fine, but there are a few errors / warnings from XPRA and some quality issues with the HTML5 client on high resolution displays (e.g. retina). Can you please help me understand or resolve these? You can find the xpra.conf here: https://github.com/ffeldhaus/docker-wireshark/blob/master/xpra.conf Here?s the output from the XPRA start: 2019-10-11 13:54:03,413 Error: cannot enable SSH socket upgrades: 2019-10-11 13:54:03,413 No module named 'paramiko' 2019-10-11 13:54:03,414 created wss socket '0.0.0.0:14500' 2019-10-11 13:54:03,416 cannot access python uinput module: 2019-10-11 13:54:03,416 No module named 'uinput' _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian Current Operating System: Linux ad83385fffde 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64 Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 console=ttyS1 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text Build Date: 05 March 2019 08:11:12PM xorg-server 2:1.20.4-1 (https://www.debian.org/support) Current version of pixman: 0.36.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.S1.log", Time: Fri Oct 11 13:54:05 2019 (++) Using config file: "/etc/xpra/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" 2019-10-11 13:54:09,129 Error adding xauth entry for :0 2019-10-11 13:54:09,129 using command "xauth -f /home/wireshark/.Xauthority add :0 MIT-MAGIC-COOKIE-1 aeb28935775b4c6189a3b88cb67f90d3": 2019-10-11 13:54:09,129 [Errno 2] No such file or directory: 'xauth': 'xauth' 2019-10-11 13:54:09,252 created unix domain socket '/run/user/1000/xpra/ad83385fffde-0' 2019-10-11 13:54:09,316 pointer device emulation using XTest 2019-10-11 13:54:09,395 serving html content from '/usr/share/xpra/www' 2019-10-11 13:54:10,098 OpenGL is supported on display ':0' 2019-10-11 13:54:10,098 using 'llvmpipe (LLVM 8.0, 256 bits)' renderer Warning: failed to import GStreamer 1.x: Namespace Gst not available 2019-10-11 13:54:10,286 Error: failed to query sound subsystem: 2019-10-11 13:54:10,286 query did not return any data (Xpra:1): Gtk-CRITICAL **: 13:54:10.287: gtk_widget_realize: assertion 'widget->priv->anchored || GTK_IS_INVISIBLE (widget)' failed 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 2019-10-11 13:54:10,303 Warning: cannot watch for application menu changes without pyinotify: 2019-10-11 13:54:10,303 No module named 'pyinotify' 2019-10-11 13:54:10,307 Warning: cannot use application menu data: 2019-10-11 13:54:10,307 no python-xdg module QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-wireshark' nl80211 not found. 2019-10-11 13:54:10,497 xpra is ready. 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit 2019-10-11 13:54:10,550 2.0GB of system memory 2019-10-11 13:54:11,327 uid=1000 (wireshark), gid=1000 (wireshark) 2019-10-11 13:54:11,328 running with pid 1 on Linux Debian testing bullseye 2019-10-11 13:54:11,330 connected to X11 display :0 with 24 bit colors 2019-10-11 13:54:29,256 Error: wss request failure 2019-10-11 13:54:29,256 for client 172.17.0.1:39794: 2019-10-11 13:54:29,256 request: '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? ???"???+?/?,?0????????/5' 2019-10-11 13:54:29,256 [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:2508) Why is paramiko required? Is it necessary or helpful to use uinput with the HTML5 client or can I just ignore the message that uinput is missing? Is xauth mandatory? If so, why is it not part of the required dependencies? Is it possible to disable the sound subsystem or should I just ignore that error? What does the Gtk-CRITICAL message mean? Is pyinotify required or helpful in this scenario? What is it used for? I guess the SSLV3_ALERT_CERTIFICATE_UNKNOWN error is a result of using a self signed certificate. Is that correct? When I use this on a large display (5K), I often get very blurred output when a lot of Network packages are analyzed. That is probably expected, but the blurry images sometimes stay for several seconds and sometimes are not refreshed at all with a clear picture. I tested this on a local computer with more or less unlimited bandwidth. I tried to modify the encoding settings via xpra.conf, but it seems they had no effect. I checked the information at https://xpra.org/trac/wiki/Encodings/Debugging but I wasn?t able to fix this myself. Are there any hints for high quality encoding? Thank you very much Florian From antoine at nagafix.co.uk Sat Oct 12 04:26:26 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 12 Oct 2019 10:26:26 +0700 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> Message-ID: <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote: > A while ago, I created a Docker image to run Wireshark via a Webbrowser. You can find the old mail thread here: > https://shifter-users.devloop.org.narkive.com/x5ibNYzP/winswitch-xpra-running-wireshark-in-docker-container > > I completely forgot about this, but recently discovered that it seems to be really popular (over 200K downloads of the image to date) and I decided to update the image (and will ask people to donate to Wireshark and XPRA if they like the image). > > Mostly it is working fine, but there are a few errors / warnings from XPRA and some quality issues with the HTML5 client on high resolution displays (e.g. retina). Can you please help me understand or resolve these? > > You can find the xpra.conf here: > https://github.com/ffeldhaus/docker-wireshark/blob/master/xpra.conf "no-printing" is not a valid option, use "printing=no" "ssl=www" should not be used since xpra 2.4, the default is better. > Here?s the output from the XPRA start: > 2019-10-11 13:54:03,413 Error: cannot enable SSH socket upgrades: > 2019-10-11 13:54:03,413 No module named 'paramiko' With paramiko installed, xpra can upgrade TCP sockets to support SSH: https://xpra.org/trac/ticket/1920 So you can then connect using a regular SSH client as transport (ie: plink or openssh), or xpra's built-in SSH client (also using paramiko). > 2019-10-11 13:54:03,414 created wss socket '0.0.0.0:14500' > 2019-10-11 13:54:03,416 cannot access python uinput module: > 2019-10-11 13:54:03,416 No module named 'uinput' This harmless, can be used for simulating touch devices: https://www.xpra.org/trac/ticket/1615 > _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. > > X.Org X Server 1.20.4 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian > Current Operating System: Linux ad83385fffde 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64 > Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 console=ttyS1 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text > Build Date: 05 March 2019 08:11:12PM > xorg-server 2:1.20.4-1 (https://www.debian.org/support) > Current version of pixman: 0.36.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.S1.log", Time: Fri Oct 11 13:54:05 2019 > (++) Using config file: "/etc/xpra/xorg.conf" > (==) Using system config directory "/usr/share/X11/xorg.conf.d" > 2019-10-11 13:54:09,129 Error adding xauth entry for :0 > 2019-10-11 13:54:09,129 using command "xauth -f /home/wireshark/.Xauthority add :0 MIT-MAGIC-COOKIE-1 aeb28935775b4c6189a3b88cb67f90d3": > 2019-10-11 13:54:09,129 [Errno 2] No such file or directory: 'xauth': 'xauth' Probably not needed in a container, but safer to have it. > 2019-10-11 13:54:09,252 created unix domain socket '/run/user/1000/xpra/ad83385fffde-0' > 2019-10-11 13:54:09,316 pointer device emulation using XTest > 2019-10-11 13:54:09,395 serving html content from '/usr/share/xpra/www' > 2019-10-11 13:54:10,098 OpenGL is supported on display ':0' > 2019-10-11 13:54:10,098 using 'llvmpipe (LLVM 8.0, 256 bits)' renderer > Warning: failed to import GStreamer 1.x: > Namespace Gst not available > 2019-10-11 13:54:10,286 Error: failed to query sound subsystem: > 2019-10-11 13:54:10,286 query did not return any data Install the python gstreamer bindings to support audio forwarding. Or disable audio with "speaker=no" and "microphone=no". > (Xpra:1): Gtk-CRITICAL **: 13:54:10.287: gtk_widget_realize: assertion 'widget->priv->anchored || GTK_IS_INVISIBLE (widget)' failed Safe to ignore, we can't silence it. Something in GTK. > 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 > 2019-10-11 13:54:10,303 Warning: cannot watch for application menu changes without pyinotify: > 2019-10-11 13:54:10,303 No module named 'pyinotify' Not needed unless you want the client to be able to start new commands using a menu GUI. Be aware than since v3, users can start new commands when connected to the server. Use "start-new-commands=no" to disable this capability. > 2019-10-11 13:54:10,307 Warning: cannot use application menu data: > 2019-10-11 13:54:10,307 no python-xdg module Same as pyinotify above, the "new commands menu GUI" will not be available without this. > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-wireshark' > nl80211 not found. This is from wireshark. > 2019-10-11 13:54:10,497 xpra is ready. > 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit > 2019-10-11 13:54:10,550 2.0GB of system memory > 2019-10-11 13:54:11,327 uid=1000 (wireshark), gid=1000 (wireshark) > 2019-10-11 13:54:11,328 running with pid 1 on Linux Debian testing bullseye > 2019-10-11 13:54:11,330 connected to X11 display :0 with 24 bit colors > 2019-10-11 13:54:29,256 Error: wss request failure > 2019-10-11 13:54:29,256 for client 172.17.0.1:39794: > 2019-10-11 13:54:29,256 request: '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? > ???"???+?/?,?0????????/5' > 2019-10-11 13:54:29,256 [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:2508) SSL client misconfiguration? Summary:> Why is paramiko required? No. > Is it necessary or helpful to use uinput with the HTML5 client or can I just ignore the message that uinput is missing? Safe to ignore. > Is xauth mandatory? If so, why is it not part of the required dependencies? Not mandatory. > Is it possible to disable the sound subsystem or should I just ignore that error? Disabling it will make the server startup faster. > What does the Gtk-CRITICAL message mean? Some internal GTK thing. > Is pyinotify required or helpful in this scenario? What is it used for? Not required. > I guess the SSLV3_ALERT_CERTIFICATE_UNKNOWN error is a result of using a self signed certificate. Is that correct? No idea how you configured SSL or how you connected to it, so it's impossible to say for certain. You can find more information here: https://xpra.org/trac/wiki/Encryption/SSL > When I use this on a large display (5K), I often get very blurred output when a lot of Network packages are analyzed. That is probably expected, but the blurry images sometimes stay for several seconds and sometimes are not refreshed at all with a clear picture. Some applications are known to refresh their windows regularly, even when nothing has actually changed on screen, this causes problems with xpra's builtin heuristics which then keep the picture quality lower than desired to try to keep up with the updates. Otherwise, the picture is always eventually refreshed with a lossless one pretty quickly. Also, be aware that I don't have a 5K display so this has never been tested with windows that big - so some things may need tweaking to improve the experience. For a start, we there is a known issue with the html5 client on macos hi-dpi displays: https://xpra.org/trac/ticket/2410 > I tested this on a local computer with more or less unlimited bandwidth. I tried to modify the encoding settings via xpra.conf, but it seems they had no effect. I checked the information at https://xpra.org/trac/wiki/Encodings/Debugging but I wasn?t able to fix this myself. Are there any hints for high quality encoding? The best way would be to just add a new hint so we map wireshark to a "text" mode: https://xpra.org/trac/browser/xpra/trunk/src/content-type https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf Alternatively, you should be able to get pixel perfect screen updates just by increasing the "min-quality" parameter. Cheers, Antoine > > Thank you very much > Florian From info1 at wolframhumann.de Mon Oct 14 10:35:45 2019 From: info1 at wolframhumann.de (Wolfram Humann) Date: Mon, 14 Oct 2019 11:35:45 +0200 Subject: [winswitch] Clipboard paste in Eclipse Message-ID: This might be an Eclipse issue at least partially but maybe you can still help. Client: Win 10, xpra 3.0 r24039 Server: RHEL, xpra 3.0 r23788 Problem is that I can't copy on Windows and paste to Eclipse on RHEL. Pasting to Konsole does work. Using gtk_view_clipboard.py (by the way: it would be nice to be able to copy from the messages at the bottom of the tool) I see the copied text in the clipboard. "Get targets" gives: ('text/plain', 'text/plain;charset=utf-8', 'UTF8_STRING') Can't past to Eclipse. But when I copy the text to the entry and "Set target" to UTF8_STRING then "Get targets" gives: ('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'UTF8_STRING') Now it is possible to paste to Eclipse. Any idea? Best regards Wolfram Another note: would be nice if could point out *how *to start gtk_view_clipboard.py. E.g. for me it's: "python /usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_view_clipboard.py" From florian.feldhaus at gmail.com Mon Oct 14 12:36:43 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Mon, 14 Oct 2019 13:36:43 +0200 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> Message-ID: <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> Thanks a lot for your input, very helpful. I have a few follow up questions inline, but first let me ask 2 new questions: Is there a way to donate to XPRA? I?d be glad to donate myself and refer users of my Docker container to donate to the XPRA project as it wouldn?t be possible without the great job you are doing. I couldn?t find anything on the XPRA or Winswitch sites. When using the HTML5 client, I have consistently problems with multiple OS (checked Linux and Mac OS) regardless of resolution with Firefox and Chrome when maximizing Wireshark and then trying to use the scrollbar on the right side. It seems that the cursor is generally off to the left in this situation. If I make the Wireshark window a bit smaller than maximized, everything is still fine. I couldn?t find any ticket on this. Is this a known issue? Otherwise I?ll open a ticket. > Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via shifter-users : > > On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote: >> 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 >> 2019-10-11 13:54:10,303 Warning: cannot watch for application menu changes without pyinotify: >> 2019-10-11 13:54:10,303 No module named 'pyinotify' > Not needed unless you want the client to be able to start new commands using a menu GUI. > Be aware than since v3, users can start new commands when connected to the server. Use "start-new-commands=no" to disable this capability. Is there a way to completely disable the XPRA menu in the HTML5 client? It is not needed in my case and could be confusing for users. >> 2019-10-11 13:54:10,497 xpra is ready. >> 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit >> 2019-10-11 13:54:10,550 2.0GB of system memory >> 2019-10-11 13:54:11,327 uid=1000 (wireshark), gid=1000 (wireshark) >> 2019-10-11 13:54:11,328 running with pid 1 on Linux Debian testing bullseye >> 2019-10-11 13:54:11,330 connected to X11 display :0 with 24 bit colors >> 2019-10-11 13:54:29,256 Error: wss request failure >> 2019-10-11 13:54:29,256 for client 172.17.0.1:39794: >> 2019-10-11 13:54:29,256 request: '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? >> ???"???+?/?,?0????????/5' >> 2019-10-11 13:54:29,256 [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:2508) > SSL client misconfiguration? I followed the exact steps in https://xpra.org/trac/wiki/Encryption/SSL and still have the issue. I have lots of these log entries, but will retry with a trusted certificate. One thing I found out is, that when I open the HTML5 client in a Browser it is asking for a client certificate. I do have client certificates installed, but don?t want to use them and click on cancel. Could it be, that client certificates are causing this error? >> When I use this on a large display (5K), I often get very blurred output when a lot of Network packages are analyzed. That is probably expected, but the blurry images sometimes stay for several seconds and sometimes are not refreshed at all with a clear picture. > Some applications are known to refresh their windows regularly, even when nothing has actually changed on screen, this causes problems with xpra's builtin heuristics which then keep the picture quality lower than desired to try to keep up with the updates. > Otherwise, the picture is always eventually refreshed with a lossless one pretty quickly. > > Also, be aware that I don't have a 5K display so this has never been tested with windows that big - so some things may need tweaking to improve the experience. > For a start, we there is a known issue with the html5 client on macos hi-dpi displays: > https://xpra.org/trac/ticket/2410 > >> I tested this on a local computer with more or less unlimited bandwidth. I tried to modify the encoding settings via xpra.conf, but it seems they had no effect. I checked the information at https://xpra.org/trac/wiki/Encodings/Debugging but I wasn?t able to fix this myself. Are there any hints for high quality encoding? > The best way would be to just add a new hint so we map wireshark to a "text" mode: > https://xpra.org/trac/browser/xpra/trunk/src/content-type > https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf > > Alternatively, you should be able to get pixel perfect screen updates just by increasing the "min-quality" parameter. I added a hint for Wireshark to be mapped to text mode and the quality is perfect now. Even if a lot of packages are analyzed, only approx. 500KB/s of bandwidth are used to deliver the updates to the client! Can we add Wireshark to the official 50_class.conf or should I just do it for my docker deployment? I still get a lot of DPI errors, even when connecting with devices with lower resolutions on Linux: 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) 2019-10-14 08:30:02,463 you may experience scaling problems, such as huge or small fonts, etc 2019-10-14 08:30:02,463 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 (max 8192x4096) I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to have an effect. I checked the information about Xdummy here https://xpra.org/trac/wiki/Xdummy but it seems that is already used by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf | tail -n1?: # Selecting virtual X server: xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf How can I verify if all required packages are installed and how do I solve the DPI issues? Thanks again for your great support Florian From antoine at nagafix.co.uk Mon Oct 14 13:05:04 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 14 Oct 2019 19:05:04 +0700 Subject: [winswitch] Clipboard paste in Eclipse In-Reply-To: References: Message-ID: <571fa386-3052-c588-a5ca-29594b5dbb0f@nagafix.co.uk> On 14/10/2019 16:35, Wolfram Humann via shifter-users wrote: > This might be an Eclipse issue at least partially but maybe you can still > help. > Client: Win 10, xpra 3.0 r24039 > Server: RHEL, xpra 3.0 r23788 > Problem is that I can't copy on Windows and paste to Eclipse on RHEL. > Pasting to Konsole does work. I'll take a look, thanks for reporting it. > Using gtk_view_clipboard.py (by the way: it would be nice to be able to > copy from the messages at the bottom of the tool) That sounded like a good idea until I tried it: selecting the messages triggers clipboard messages which causes more messages to be added and what you wanted to copy has now scrolled offscreen! > I see the copied text in > the clipboard. > "Get targets" gives: ('text/plain', 'text/plain;charset=utf-8', > 'UTF8_STRING') > Can't past to Eclipse. > But when I copy the text to the entry and "Set target" to UTF8_STRING then > "Get targets" gives: ('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'UTF8_STRING') > Now it is possible to paste to Eclipse. > > Any idea? > Best regards > Wolfram > > Another note: would be nice if could > point out *how *to start gtk_view_clipboard.py. E.g. for me it's: > "python > /usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_view_clipboard.py" Good idea. We will soon have a "xpra clipboard-tool" to do that reliably on all platforms: https://xpra.org/trac/ticket/2443 Cheers, Antoine From antoine at nagafix.co.uk Mon Oct 14 13:07:42 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 14 Oct 2019 19:07:42 +0700 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> Message-ID: <01b38be0-37d6-c547-6b7d-4988419c6cd4@nagafix.co.uk> On 14/10/2019 18:36, Florian Feldhaus wrote: > Thanks a lot for your input, very helpful. I have a few follow up > questions inline, but first let me ask 2 new questions: > > Is there a way to donate to XPRA? I?d be glad to donate myself and refer > users of my Docker container to donate to the XPRA project as it > wouldn?t be possible without the great job you are doing. I couldn?t > find anything on the XPRA or Winswitch sites. That's good idea, I'll try to set something up after I inquire about the legal constraints of it. > When using the HTML5 client, I have consistently problems with multiple > OS (checked Linux and Mac OS) regardless of resolution with Firefox and > Chrome when maximizing Wireshark and then trying to use the scrollbar on > the right side. It seems that the cursor is generally off to the left in > this situation. If I make the Wireshark window a bit smaller than > maximized, everything is still fine. I couldn?t find any ticket on this. > Is this a known issue? Otherwise I?ll open a ticket. Please do. Sounds like the browser window is slightly too small. Cheers, Antoine > >> Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via >> shifter-users > >: >> >> On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote: >>> 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 >>> 2019-10-11 13:54:10,303 Warning: cannot watch for application menu >>> changes without pyinotify: >>> 2019-10-11 13:54:10,303 ?No module named 'pyinotify' >> Not needed unless you want the client to be able to start new commands >> using a menu GUI. >> Be aware than since v3, users can start new commands when connected to >> the server. Use "start-new-commands=no" to disable this capability. > > Is there a way to completely disable the XPRA menu in the HTML5 client? > It is not needed in my case and could be confusing for users. > >>> 2019-10-11 13:54:10,497 xpra is ready. >>> 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit >>> 2019-10-11 13:54:10,550 2.0GB of system memory >>> 2019-10-11 13:54:11,327 ?uid=1000 (wireshark), gid=1000 (wireshark) >>> 2019-10-11 13:54:11,328 ?running with pid 1 on Linux Debian testing >>> bullseye >>> 2019-10-11 13:54:11,330 ?connected to X11 display :0 with 24 bit colors >>> 2019-10-11 13:54:29,256 Error: wss request failure >>> 2019-10-11 13:54:29,256 ?for client 172.17.0.1:39794: >>> 2019-10-11 13:54:29,256 ?request: >>> '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? >>> ???"???+?/?,?0????????/5' >>> 2019-10-11 13:54:29,256 ?[SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 >>> alert certificate unknown (_ssl.c:2508) >> SSL client misconfiguration? > > I followed the exact steps in > https://xpra.org/trac/wiki/Encryption/SSL?and still have the issue. I > have lots of these log entries, but will retry with a trusted > certificate. One thing I found out is, that when I open the HTML5 client > in a Browser it is asking for a client certificate. I do have client > certificates installed, but don?t want to use them and click on cancel. > Could it be, that client certificates are causing this error? > >>> When I use this on a large display (5K), I often get very blurred >>> output when a lot of Network packages are analyzed. That is probably >>> expected, but the blurry images sometimes stay for several seconds >>> and sometimes are not refreshed at all with a clear picture. >> Some applications are known to refresh their windows regularly, even >> when nothing has actually changed on screen, this causes problems with >> xpra's builtin heuristics which then keep the picture quality lower >> than desired to try to keep up with the updates. >> Otherwise, the picture is always eventually refreshed with a lossless >> one pretty quickly. >> >> Also, be aware that I don't have a 5K display so this has never been >> tested with windows that big - so some things may need tweaking to >> improve the experience. >> For a start, we there is a known issue with the html5 client on macos >> hi-dpi displays: >> https://xpra.org/trac/ticket/2410 >> >>> I tested this on a local computer with more or less unlimited >>> bandwidth. I tried to modify the encoding settings via xpra.conf, but >>> it seems they had no effect. I checked the information at >>> https://xpra.org/trac/wiki/Encodings/Debugging >>> but I wasn?t able to >>> fix this myself. Are there any hints for high quality encoding? >> The best way would be to just add a new hint so we map wireshark to a >> "text" mode: >> https://xpra.org/trac/browser/xpra/trunk/src/content-type >> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf >> >> Alternatively, you should be able to get pixel perfect screen updates >> just by increasing the "min-quality" parameter. > > I added a hint for Wireshark to be mapped to text mode and the quality > is perfect now. Even if a lot of packages are analyzed, only approx. > 500KB/s of bandwidth are used to deliver the updates to the client! Can > we add Wireshark to the official 50_class.conf or should I just do it > for my docker deployment? > > I still get a lot of DPI errors, even when connecting with devices with > lower resolutions on Linux: > 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) > 2019-10-14 08:30:02,463??you may experience scaling problems, such as > huge or small fonts, etc > 2019-10-14 08:30:02,463??to fix this issue, try the dpi switch, or use a > patched Xorg dummy driver > 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 > (max 8192x4096) > > I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to > have an effect. I checked the information about Xdummy > here?https://xpra.org/trac/wiki/Xdummy?but it seems that is already used > by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf > | tail -n1?: > # Selecting virtual X server: > xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension > GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile > ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir > ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf > > How can I verify if all required packages are installed and how do I > solve the DPI issues? > > Thanks again for your great support > Florian From florian.feldhaus at gmail.com Mon Oct 14 17:00:24 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Mon, 14 Oct 2019 18:00:24 +0200 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <01b38be0-37d6-c547-6b7d-4988419c6cd4@nagafix.co.uk> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> <01b38be0-37d6-c547-6b7d-4988419c6cd4@nagafix.co.uk> Message-ID: <7BB771A0-E921-4EFD-9E3F-0A35A1B87CEA@gmail.com> Thanks for responding to my new questions, but I had an update at the end regarding the resolution / DPI issues. Can you have a look at that? > Am 14.10.2019 | KW 42 um 14:07 schrieb Antoine Martin : > > On 14/10/2019 18:36, Florian Feldhaus wrote: >> Thanks a lot for your input, very helpful. I have a few follow up >> questions inline, but first let me ask 2 new questions: >> >> Is there a way to donate to XPRA? I?d be glad to donate myself and refer >> users of my Docker container to donate to the XPRA project as it >> wouldn?t be possible without the great job you are doing. I couldn?t >> find anything on the XPRA or Winswitch sites. > That's good idea, I'll try to set something up after I inquire about the > legal constraints of it. Let me know once you have any information on donating and I?m happy to point to it and donate myself. >> When using the HTML5 client, I have consistently problems with multiple >> OS (checked Linux and Mac OS) regardless of resolution with Firefox and >> Chrome when maximizing Wireshark and then trying to use the scrollbar on >> the right side. It seems that the cursor is generally off to the left in >> this situation. If I make the Wireshark window a bit smaller than >> maximized, everything is still fine. I couldn?t find any ticket on this. >> Is this a known issue? Otherwise I?ll open a ticket. > Please do. > Sounds like the browser window is slightly too small. I created ticket http://xpra.org/trac/ticket/2444 for this. >>> Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via >>> shifter-users >> >: >>> >>> On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote: >>>> 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 >>>> 2019-10-11 13:54:10,303 Warning: cannot watch for application menu >>>> changes without pyinotify: >>>> 2019-10-11 13:54:10,303 No module named 'pyinotify' >>> Not needed unless you want the client to be able to start new commands >>> using a menu GUI. >>> Be aware than since v3, users can start new commands when connected to >>> the server. Use "start-new-commands=no" to disable this capability. >> >> Is there a way to completely disable the XPRA menu in the HTML5 client? >> It is not needed in my case and could be confusing for users. >> >>>> 2019-10-11 13:54:10,497 xpra is ready. >>>> 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit >>>> 2019-10-11 13:54:10,550 2.0GB of system memory >>>> 2019-10-11 13:54:11,327 uid=1000 (wireshark), gid=1000 (wireshark) >>>> 2019-10-11 13:54:11,328 running with pid 1 on Linux Debian testing >>>> bullseye >>>> 2019-10-11 13:54:11,330 connected to X11 display :0 with 24 bit colors >>>> 2019-10-11 13:54:29,256 Error: wss request failure >>>> 2019-10-11 13:54:29,256 for client 172.17.0.1:39794: >>>> 2019-10-11 13:54:29,256 request: >>>> '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? >>>> ???"???+?/?,?0????????/5' >>>> 2019-10-11 13:54:29,256 [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 >>>> alert certificate unknown (_ssl.c:2508) >>> SSL client misconfiguration? >> >> I followed the exact steps in >> https://xpra.org/trac/wiki/Encryption/SSL and still have the issue. I >> have lots of these log entries, but will retry with a trusted >> certificate. One thing I found out is, that when I open the HTML5 client >> in a Browser it is asking for a client certificate. I do have client >> certificates installed, but don?t want to use them and click on cancel. >> Could it be, that client certificates are causing this error? >> >>>> When I use this on a large display (5K), I often get very blurred >>>> output when a lot of Network packages are analyzed. That is probably >>>> expected, but the blurry images sometimes stay for several seconds >>>> and sometimes are not refreshed at all with a clear picture. >>> Some applications are known to refresh their windows regularly, even >>> when nothing has actually changed on screen, this causes problems with >>> xpra's builtin heuristics which then keep the picture quality lower >>> than desired to try to keep up with the updates. >>> Otherwise, the picture is always eventually refreshed with a lossless >>> one pretty quickly. >>> >>> Also, be aware that I don't have a 5K display so this has never been >>> tested with windows that big - so some things may need tweaking to >>> improve the experience. >>> For a start, we there is a known issue with the html5 client on macos >>> hi-dpi displays: >>> https://xpra.org/trac/ticket/2410 >>> >>>> I tested this on a local computer with more or less unlimited >>>> bandwidth. I tried to modify the encoding settings via xpra.conf, but >>>> it seems they had no effect. I checked the information at >>>> https://xpra.org/trac/wiki/Encodings/Debugging >>>> but I wasn?t able to >>>> fix this myself. Are there any hints for high quality encoding? >>> The best way would be to just add a new hint so we map wireshark to a >>> "text" mode: >>> https://xpra.org/trac/browser/xpra/trunk/src/content-type >>> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf >>> >>> Alternatively, you should be able to get pixel perfect screen updates >>> just by increasing the "min-quality" parameter. >> >> I added a hint for Wireshark to be mapped to text mode and the quality >> is perfect now. Even if a lot of packages are analyzed, only approx. >> 500KB/s of bandwidth are used to deliver the updates to the client! Can >> we add Wireshark to the official 50_class.conf or should I just do it >> for my docker deployment? >> >> I still get a lot of DPI errors, even when connecting with devices with >> lower resolutions on Linux: >> 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) >> 2019-10-14 08:30:02,463 you may experience scaling problems, such as >> huge or small fonts, etc >> 2019-10-14 08:30:02,463 to fix this issue, try the dpi switch, or use a >> patched Xorg dummy driver >> 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 >> (max 8192x4096) >> >> I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to >> have an effect. I checked the information about Xdummy >> here https://xpra.org/trac/wiki/Xdummy but it seems that is already used >> by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf >> | tail -n1?: >> # Selecting virtual X server: >> xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension >> GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile >> ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir >> ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf >> >> How can I verify if all required packages are installed and how do I >> solve the DPI issues? Can you have a look at the section above from my last mail? Thanks Florian From mgrenier25 at gmail.com Mon Oct 14 18:08:23 2019 From: mgrenier25 at gmail.com (Mathieu Grenier) Date: Mon, 14 Oct 2019 13:08:23 -0400 Subject: [winswitch] I could use some help setting this thing up Message-ID: I would like to set this up on 3 devices, a htpc running windows 10 a laptop on debian 10 and a dual boot win10/debian 10 desktop pc I could not find much info on the windows part. I am also not sure this is really what I need, I would like to use the debian laptop as a second monitor on the htpc and the desktop. Any help would be appreciated. Thanks -- Mathieu From antoine at nagafix.co.uk Tue Oct 15 04:12:11 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 15 Oct 2019 10:12:11 +0700 Subject: [winswitch] I could use some help setting this thing up In-Reply-To: References: Message-ID: <7923efb9-3d70-cc58-2f28-c30b21f6ca24@nagafix.co.uk> On 15/10/2019 00:08, Mathieu Grenier via shifter-users wrote: > I would like to set this up on 3 devices, > a htpc running windows 10 > a laptop on debian 10 > and a dual boot win10/debian 10 desktop pc > > I could not find much info on the windows part. I am also not sure this is > really what I need, I would like to use the debian laptop as a second > monitor on the htpc and the desktop. I am not aware of any Linux software that will allow you to do that. MS Windows does support this: https://www.techadvisor.co.uk/how-to/laptop/laptop-second-monitor-3674679/ Cheers, Antoine > > Any help would be appreciated. > Thanks > From varvello at yahoo.com Tue Oct 15 15:40:57 2019 From: varvello at yahoo.com (Davide Varvello) Date: Tue, 15 Oct 2019 14:40:57 +0000 (UTC) Subject: [winswitch] Window-switch and OSX 10.15 Catalina References: <1690088903.1201267.1571150457395.ref@mail.yahoo.com> Message-ID: <1690088903.1201267.1571150457395@mail.yahoo.com> Hi Antoine, Is there a version of win-switch working on Catalina? I've not upgraded my mac yet because I'm worrying about the compatibility. TIADavide From antoine at nagafix.co.uk Tue Oct 15 16:16:27 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 15 Oct 2019 22:16:27 +0700 Subject: [winswitch] Window-switch and OSX 10.15 Catalina In-Reply-To: <1690088903.1201267.1571150457395@mail.yahoo.com> References: <1690088903.1201267.1571150457395.ref@mail.yahoo.com> <1690088903.1201267.1571150457395@mail.yahoo.com> Message-ID: On 15/10/2019 21:40, Davide Varvello via shifter-users wrote: > Hi Antoine, > Is there a version of win-switch working on Catalina? There isn't, and none is planned. winswitch is bitrotting as I just don't have the time to maintain it or port it to python3. > I've not upgraded my mac yet because I'm worrying about the compatibility. There may be problems running on Catalina: all applications have to be notarized now. http://xpra.org/trac/ticket/2441 Cheers, Antoine > TIADavide From florian.feldhaus at gmail.com Wed Oct 16 15:51:55 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Wed, 16 Oct 2019 16:51:55 +0200 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <7BB771A0-E921-4EFD-9E3F-0A35A1B87CEA@gmail.com> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> <01b38be0-37d6-c547-6b7d-4988419c6cd4@nagafix.co.uk> <7BB771A0-E921-4EFD-9E3F-0A35A1B87CEA@gmail.com> Message-ID: I was able to solve most issues now, the SSH error went away after I used a trusted certificate. I still have issues with DPI settings (see section at the end) and would be glad to receive some hints how to make DPI work. The offset issue is also still open and I responded in the ticket I created. I added an Acknowledgement section to the README asking to support the Open Source projects which the Docker Image is built from: https://github.com/ffeldhaus/docker-wireshark#acknowledgements Thanks for all your help! Florian > Am 14.10.2019 | KW 42 um 18:00 schrieb Florian Feldhaus : > > Thanks for responding to my new questions, but I had an update at the end regarding the resolution / DPI issues. Can you have a look at that? > >> Am 14.10.2019 | KW 42 um 14:07 schrieb Antoine Martin >: >> >> On 14/10/2019 18:36, Florian Feldhaus wrote: >>> Thanks a lot for your input, very helpful. I have a few follow up >>> questions inline, but first let me ask 2 new questions: >>> >>> Is there a way to donate to XPRA? I?d be glad to donate myself and refer >>> users of my Docker container to donate to the XPRA project as it >>> wouldn?t be possible without the great job you are doing. I couldn?t >>> find anything on the XPRA or Winswitch sites. >> That's good idea, I'll try to set something up after I inquire about the >> legal constraints of it. > > Let me know once you have any information on donating and I?m happy to point to it and donate myself. > >>> When using the HTML5 client, I have consistently problems with multiple >>> OS (checked Linux and Mac OS) regardless of resolution with Firefox and >>> Chrome when maximizing Wireshark and then trying to use the scrollbar on >>> the right side. It seems that the cursor is generally off to the left in >>> this situation. If I make the Wireshark window a bit smaller than >>> maximized, everything is still fine. I couldn?t find any ticket on this. >>> Is this a known issue? Otherwise I?ll open a ticket. >> Please do. >> Sounds like the browser window is slightly too small. > > I created ticket http://xpra.org/trac/ticket/2444 for this. > >>>> Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via >>>> shifter-users >>>> >>: >>>> >>>> On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote: >>>>> 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45 >>>>> 2019-10-11 13:54:10,303 Warning: cannot watch for application menu >>>>> changes without pyinotify: >>>>> 2019-10-11 13:54:10,303 No module named 'pyinotify' >>>> Not needed unless you want the client to be able to start new commands >>>> using a menu GUI. >>>> Be aware than since v3, users can start new commands when connected to >>>> the server. Use "start-new-commands=no" to disable this capability. >>> >>> Is there a way to completely disable the XPRA menu in the HTML5 client? >>> It is not needed in my case and could be confusing for users. >>> >>>>> 2019-10-11 13:54:10,497 xpra is ready. >>>>> 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit >>>>> 2019-10-11 13:54:10,550 2.0GB of system memory >>>>> 2019-10-11 13:54:11,327 uid=1000 (wireshark), gid=1000 (wireshark) >>>>> 2019-10-11 13:54:11,328 running with pid 1 on Linux Debian testing >>>>> bullseye >>>>> 2019-10-11 13:54:11,330 connected to X11 display :0 with 24 bit colors >>>>> 2019-10-11 13:54:29,256 Error: wss request failure >>>>> 2019-10-11 13:54:29,256 for client 172.17.0.1:39794: >>>>> 2019-10-11 13:54:29,256 request: >>>>> '?1?D5a>G????(????3???l??YCE?? D????????????{}?3?'o? >>>>> ???"???+?/?,?0????????/5' >>>>> 2019-10-11 13:54:29,256 [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 >>>>> alert certificate unknown (_ssl.c:2508) >>>> SSL client misconfiguration? >>> >>> I followed the exact steps in >>> https://xpra.org/trac/wiki/Encryption/SSL and still have the issue. I >>> have lots of these log entries, but will retry with a trusted >>> certificate. One thing I found out is, that when I open the HTML5 client >>> in a Browser it is asking for a client certificate. I do have client >>> certificates installed, but don?t want to use them and click on cancel. >>> Could it be, that client certificates are causing this error? >>> >>>>> When I use this on a large display (5K), I often get very blurred >>>>> output when a lot of Network packages are analyzed. That is probably >>>>> expected, but the blurry images sometimes stay for several seconds >>>>> and sometimes are not refreshed at all with a clear picture. >>>> Some applications are known to refresh their windows regularly, even >>>> when nothing has actually changed on screen, this causes problems with >>>> xpra's builtin heuristics which then keep the picture quality lower >>>> than desired to try to keep up with the updates. >>>> Otherwise, the picture is always eventually refreshed with a lossless >>>> one pretty quickly. >>>> >>>> Also, be aware that I don't have a 5K display so this has never been >>>> tested with windows that big - so some things may need tweaking to >>>> improve the experience. >>>> For a start, we there is a known issue with the html5 client on macos >>>> hi-dpi displays: >>>> https://xpra.org/trac/ticket/2410 >>>> >>>>> I tested this on a local computer with more or less unlimited >>>>> bandwidth. I tried to modify the encoding settings via xpra.conf, but >>>>> it seems they had no effect. I checked the information at >>>>> https://xpra.org/trac/wiki/Encodings/Debugging >>>>> but I wasn?t able to >>>>> fix this myself. Are there any hints for high quality encoding? >>>> The best way would be to just add a new hint so we map wireshark to a >>>> "text" mode: >>>> https://xpra.org/trac/browser/xpra/trunk/src/content-type >>>> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf >>>> >>>> Alternatively, you should be able to get pixel perfect screen updates >>>> just by increasing the "min-quality" parameter. >>> >>> I added a hint for Wireshark to be mapped to text mode and the quality >>> is perfect now. Even if a lot of packages are analyzed, only approx. >>> 500KB/s of bandwidth are used to deliver the updates to the client! Can >>> we add Wireshark to the official 50_class.conf or should I just do it >>> for my docker deployment? >>> >>> I still get a lot of DPI errors, even when connecting with devices with >>> lower resolutions on Linux: >>> 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) >>> 2019-10-14 08:30:02,463 you may experience scaling problems, such as >>> huge or small fonts, etc >>> 2019-10-14 08:30:02,463 to fix this issue, try the dpi switch, or use a >>> patched Xorg dummy driver >>> 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 >>> (max 8192x4096) >>> >>> I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to >>> have an effect. I checked the information about Xdummy >>> here https://xpra.org/trac/wiki/Xdummy but it seems that is already used >>> by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf >>> | tail -n1?: >>> # Selecting virtual X server: >>> xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension >>> GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile >>> ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir >>> ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf >>> >>> How can I verify if all required packages are installed and how do I >>> solve the DPI issues? > > Can you have a look at the section above from my last mail? > > Thanks > Florian From antoine at nagafix.co.uk Wed Oct 16 17:41:12 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 16 Oct 2019 23:41:12 +0700 Subject: [winswitch] Xpra 3.0 Windows very slow ssh login In-Reply-To: <55ece208-bedb-438e-bcf3-d56f4b3dcc02@wssddc.com> References: <55ece208-bedb-438e-bcf3-d56f4b3dcc02@wssddc.com> Message-ID: <87ff0dfb-7695-d6ed-189a-2951fed97da4@nagafix.co.uk> On 02/10/2019 12:31, Bob Babcock wrote: > Antoine Martin via shifter-users wrote: >> In the meantime, you can switch to plink instead of the paramiko backend: > > Confirmed, on Windows 7 I see no hangup at the ssh login dialog when > using plink and xpra 3.0.0.0. With xpra 3.0.1 the problem has been fixed. You can find a pre-release build in the windows beta area: http://xpra.org/beta/windows/ More details on this GTK "feature" here: https://xpra.org/trac/ticket/2448#comment:1 Cheers, Antoine > >> The stable repository actually has 3.0 proper, which is very slightly >> newer than this. >> You should always add both stable and beta repositories, as the beta >> one is only a supplemental one, which may or may not have packages in it. > > I'm not ready to experiment with version 4 yet, so I disabled the beta > repository, uninstalled *xpra* and reinstalled.? That does indeed give a > slightly newer 3.0.? As I recall, I added the beta repo a while back to > fix some problem or conflict with updating.? I forget the details, but > there's no problem today. > > Thanks. > From antoine at nagafix.co.uk Wed Oct 16 18:06:11 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 17 Oct 2019 00:06:11 +0700 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> Message-ID: <1966cbb0-b7ed-c69e-4d07-95fba82a9486@nagafix.co.uk> (snip) > I followed the exact steps in > https://xpra.org/trac/wiki/Encryption/SSL?and still have the issue. I > have lots of these log entries, but will retry with a trusted > certificate. One thing I found out is, that when I open the HTML5 client > in a Browser it is asking for a client certificate. I do have client > certificates installed, but don?t want to use them and click on cancel. > Could it be, that client certificates are causing this error? That's odd, a default SSL configuration does not require any client certificates. Most browsers will just reject self-signed server certificates, though some will allow them when connection to "localhost". (snip) >>> I tested this on a local computer with more or less unlimited >>> bandwidth. I tried to modify the encoding settings via xpra.conf, but >>> it seems they had no effect. I checked the information at >>> https://xpra.org/trac/wiki/Encodings/Debugging >>> but I wasn?t able to >>> fix this myself. Are there any hints for high quality encoding? >> The best way would be to just add a new hint so we map wireshark to a >> "text" mode: >> https://xpra.org/trac/browser/xpra/trunk/src/content-type >> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf >> >> Alternatively, you should be able to get pixel perfect screen updates >> just by increasing the "min-quality" parameter. > > I added a hint for Wireshark to be mapped to text mode and the quality > is perfect now. > Even if a lot of packages are analyzed, only approx. > 500KB/s of bandwidth are used to deliver the updates to the client! Can > we add Wireshark to the official 50_class.conf or should I just do it > for my docker deployment? Please submit the change so that other xpra users can benefit. This applies to all the applications I do not have time to test. We should be able to grow those hint files though crowdsourcing. > I still get a lot of DPI errors, even when connecting with devices with > lower resolutions on Linux: > 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) > 2019-10-14 08:30:02,463??you may experience scaling problems, such as > huge or small fonts, etc > 2019-10-14 08:30:02,463??to fix this issue, try the dpi switch, or use a > patched Xorg dummy driver > 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 > (max 8192x4096) There were no patched dummy driver "xserver-xorg-video-dummy" packages for Debian "bullseye" yet. I have just pushed some DEBs to the stable repository. Try updating your system and it should install over the default one. (untested) This should solve your DPI problems. Alternatively, you could switch to Xvfb. Bear in mind that development distributions like Debian Testing often have ABI breakage before their release. So this build may break at some point in the future. If it does, let me know and I'll push another rebuild. > I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to > have an effect. I checked the information about Xdummy > here?https://xpra.org/trac/wiki/Xdummy?but it seems that is already used > by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf > | tail -n1?: > # Selecting virtual X server: > xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension > GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile > ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir > ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf > > How can I verify if all required packages are installed and how do I > solve the DPI issues? If you followed the installation instructions, you should have all the default packages installed already. Cheers, Antoine > > Thanks again for your great support > Florian From wssddc at wssddc.com Thu Oct 17 02:41:29 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Wed, 16 Oct 2019 21:41:29 -0400 Subject: [winswitch] Xpra 3.0 Windows very slow ssh login [resolved] In-Reply-To: <87ff0dfb-7695-d6ed-189a-2951fed97da4@nagafix.co.uk> References: <55ece208-bedb-438e-bcf3-d56f4b3dcc02@wssddc.com> <87ff0dfb-7695-d6ed-189a-2951fed97da4@nagafix.co.uk> Message-ID: <8a6922f9-93dd-f875-7db9-22172b84b21e@wssddc.com> Antoine Martin via shifter-users wrote: > With xpra 3.0.1 the problem has been fixed. Confirmed.? The long hangup at the ssh login prompt is gone with 3.0.1-r24155.? (Turned off use of plink and tested briefly with Windows 7 talking to Fedora 29.) From florian.feldhaus at gmail.com Thu Oct 17 15:17:18 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Thu, 17 Oct 2019 16:17:18 +0200 Subject: [winswitch] Update for Xpra running Wireshark in Docker container In-Reply-To: <1966cbb0-b7ed-c69e-4d07-95fba82a9486@nagafix.co.uk> References: <7BF898E4-3626-4C5E-950A-83BC9C3D076F@gmail.com> <11ee878a-3905-649f-be32-c7e4cacd2927@nagafix.co.uk> <693FE200-CA26-4FFC-862D-7C1200C4E437@gmail.com> <1966cbb0-b7ed-c69e-4d07-95fba82a9486@nagafix.co.uk> Message-ID: <3B781589-A8EC-481B-A8BE-0AC694F714D9@gmail.com> Am 16.10.2019 | KW 42 um 19:06 schrieb Antoine Martin : > > (snip) >> I followed the exact steps in >> https://xpra.org/trac/wiki/Encryption/SSL and still have the issue. I >> have lots of these log entries, but will retry with a trusted >> certificate. One thing I found out is, that when I open the HTML5 client >> in a Browser it is asking for a client certificate. I do have client >> certificates installed, but don?t want to use them and click on cancel. >> Could it be, that client certificates are causing this error? > That's odd, a default SSL configuration does not require any client > certificates. > Most browsers will just reject self-signed server certificates, though > some will allow them when connection to "localhost?. If I use a certificate from a trusted CA, I do not get the SSL errors from XPRA, but with the default certificate created during installation, I do see the error SSLV3_ALERT_CERTIFICATE_UNKNOWN. Is it worth creating a ticket for that? In Chrome I?m getting asked for a client certificate, in Firefox I don?t get asked. After adding ssl-client-verify-mode=none to xpra.conf I don?t get asked for a client certificate in any browser. >>>> I tested this on a local computer with more or less unlimited >>>> bandwidth. I tried to modify the encoding settings via xpra.conf, but >>>> it seems they had no effect. I checked the information at >>>> https://xpra.org/trac/wiki/Encodings/Debugging >>>> but I wasn?t able to >>>> fix this myself. Are there any hints for high quality encoding? >>> The best way would be to just add a new hint so we map wireshark to a >>> "text" mode: >>> https://xpra.org/trac/browser/xpra/trunk/src/content-type >>> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf >>> >>> Alternatively, you should be able to get pixel perfect screen updates >>> just by increasing the "min-quality" parameter. >> >> I added a hint for Wireshark to be mapped to text mode and the quality >> is perfect now. >> Even if a lot of packages are analyzed, only approx. >> 500KB/s of bandwidth are used to deliver the updates to the client! Can >> we add Wireshark to the official 50_class.conf or should I just do it >> for my docker deployment? > Please submit the change so that other xpra users can benefit. > > This applies to all the applications I do not have time to test. > We should be able to grow those hint files though crowdsourcing. Can you help me get started? I checked out the code via svn but I?m not allowed to commit with my username ffeldhaus to trunk. I admit, I?ve not used SVN in a decade and may have done something wrong. This is what I tried: Florians-MBP-3:content-type florianfeldhaus$ svn commit -m "Mapped Wireshark to text in 50_class.conf for better display quality" Authentication realm: Xpra SVN Repository Username: ffeldhaus Password for 'ffeldhaus': **************** svn: E175013: Commit failed (details follow): svn: E175013: Access to '/svn/Xpra/!svn/me' forbidden >> I still get a lot of DPI errors, even when connecting with devices with >> lower resolutions on Linux: >> 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96) >> 2019-10-14 08:30:02,463 you may experience scaling problems, such as >> huge or small fonts, etc >> 2019-10-14 08:30:02,463 to fix this issue, try the dpi switch, or use a >> patched Xorg dummy driver >> 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896 >> (max 8192x4096) > There were no patched dummy driver "xserver-xorg-video-dummy" packages > for Debian "bullseye" yet. > I have just pushed some DEBs to the stable repository. Try updating your > system and it should install over the default one. (untested) > This should solve your DPI problems. > Alternatively, you could switch to Xvfb. > > Bear in mind that development distributions like Debian Testing often > have ABI breakage before their release. So this build may break at some > point in the future. If it does, let me know and I'll push another rebuild. > >> I tried to manually set dpi=96 in the xpra.conf but that didn?t seem to >> have an effect. I checked the information about Xdummy >> here https://xpra.org/trac/wiki/Xdummy but it seems that is already used >> by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf >> | tail -n1?: >> # Selecting virtual X server: >> xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension >> GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile >> ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir >> ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf >> >> How can I verify if all required packages are installed and how do I >> solve the DPI issues? > If you followed the installation instructions, you should have all the > default packages installed already. This is indeed fixed now with the availability of xserver-xorg-video-dummy. Thanks a lot! I need to use bullseye as Buster does not contain Wireshark 3.X and I didn?t want to build Wireshark manually. Cheers Florian From antoine at nagafix.co.uk Mon Oct 21 11:32:51 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 21 Oct 2019 17:32:51 +0700 Subject: [winswitch] Window-switch and OSX 10.15 Catalina In-Reply-To: References: <1690088903.1201267.1571150457395.ref@mail.yahoo.com> <1690088903.1201267.1571150457395@mail.yahoo.com> Message-ID: <5238d349-60f3-dd63-e07a-86b5d21e9f87@nagafix.co.uk> On 15/10/2019 22:16, Antoine Martin via shifter-users wrote: > On 15/10/2019 21:40, Davide Varvello via shifter-users wrote: >> Hi Antoine, >> Is there a version of win-switch working on Catalina? > There isn't, and none is planned. winswitch is bitrotting as I just > don't have the time to maintain it or port it to python3. > >> I've not upgraded my mac yet because I'm worrying about the compatibility. > There may be problems running on Catalina: all applications have to be > notarized now. > http://xpra.org/trac/ticket/2441 The latest beta PKG installers should now work on Catalina: https://xpra.org/beta/MacOS/ But the DMG images still do not: https://xpra.org/trac/ticket/2454 Cheers, Antoine From antoine at nagafix.co.uk Tue Oct 22 09:39:01 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 22 Oct 2019 15:39:01 +0700 Subject: [winswitch] Clipboard paste in Eclipse In-Reply-To: <571fa386-3052-c588-a5ca-29594b5dbb0f@nagafix.co.uk> References: <571fa386-3052-c588-a5ca-29594b5dbb0f@nagafix.co.uk> Message-ID: <578436c1-9ade-b068-042d-1b6d4708149b@nagafix.co.uk> On 14/10/2019 19:05, Antoine Martin via shifter-users wrote: > On 14/10/2019 16:35, Wolfram Humann via shifter-users wrote: >> This might be an Eclipse issue at least partially but maybe you can still >> help. >> Client: Win 10, xpra 3.0 r24039 >> Server: RHEL, xpra 3.0 r23788 >> Problem is that I can't copy on Windows and paste to Eclipse on RHEL. >> Pasting to Konsole does work. > I'll take a look, thanks for reporting it. This bug has been fixed: https://xpra.org/trac/ticket/2450#comment:5 >> Another note: would be nice if could >> point out *how *to start gtk_view_clipboard.py. E.g. for me it's: >> "python >> /usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_view_clipboard.py" > Good idea. We will soon have a "xpra clipboard-tool" to do that reliably > on all platforms: > https://xpra.org/trac/ticket/2443 This will also be included in the 3.0.1 release: https://xpra.org/trac/ticket/2443#comment:3 You can find 3.0.1-RC builds with these fixes here: https://xpra.org/beta/ Cheers, Antoine From totaam at xpra.org Tue Oct 22 20:40:55 2019 From: totaam at xpra.org (Antoine Martin) Date: Wed, 23 Oct 2019 02:40:55 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.1: many fixes, none critical Message-ID: <96c778d6-ff9c-7a28-bc6d-049bb82f4f0c@xpra.org> Hi, This first update to the 3.0 LTS branch fixes quite few issues, but they are all fairly minor and so there is no urgency to update if you were not affected. Release notes: * fix clipboard synchronization failures with MS Windows clients * fix window cleanup errors preventing a clean exit * fix launcher error if sharing flag is unset * fix window states wrongly getting reset * fix SSH password dialog lockups on MS Windows * fix authentication module errors (multifile, python3) * fix radio buttons on start server dialog (python3) * fix error in encoding selection fallback (python3) * fix logging error in cups printing backend (python3) * fix null bytes in X11 error text (notifications errors) * fix keyboard debug logging error * fix error querying X11 properties under pure wayland client * fix unresponsive appindicator system tray * fix GDK window scaling setting wrongly propagated to the server * fix compilation on Ubuntu Eoan Ermine * fix file download failures on MS Windows due to invalid characters * fix handling of file download errors * fix Debian bin path warnings * fix error handling in 'xpra top' * fix pyobjc API compatibility in OpenGL transparency shim * fix out of date PKG OS version requirements * fix PKG compatibility with MacOS 10.15 Catalina * fix window border color parsing failures causing errors * fix OpenGL window paint errors with some drivers * make it easier to launch test tools * update Python to 3.7.5 on MacOS * bump revision to override broken Fedora packaging * show Python version in MacOS packages * re-enable tooltips on MS Windows * update to xxhash 0.7.2 * consistent use of quotes in endpoint logging The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From antoine at nagafix.co.uk Thu Oct 24 03:57:16 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 24 Oct 2019 09:57:16 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.1: many fixes, none critical In-Reply-To: <96c778d6-ff9c-7a28-bc6d-049bb82f4f0c@xpra.org> References: <96c778d6-ff9c-7a28-bc6d-049bb82f4f0c@xpra.org> Message-ID: On 23/10/2019 02:40, Antoine Martin via shifter-users wrote: > Hi, > > This first update to the 3.0 LTS branch fixes quite few issues, but they > are all fairly minor and so there is no urgency to update if you were > not affected. I have just re-issued 3.0.1 for MS Windows and Linux DEB / RPM to apply the correct fix for a clipboard regression. More details here: https://xpra.org/trac/ticket/2450 Cheers, Antoine From ivo.couckuyt at ugent.be Sun Oct 27 19:09:17 2019 From: ivo.couckuyt at ugent.be (Ivo Couckuyt) Date: Sun, 27 Oct 2019 20:09:17 +0100 Subject: [winswitch] Dancing windows on xpra windows 10 Message-ID: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> Hi all, I have some problems with xpra windows connecting to a xpra server on ubuntu over tcp (both version 3.0.1). The gnome-terminal shrinks to 1x1 (titlebar only) and 'dances' to the bottom of the screen (same for xterm so it is not a bug in gnome I think). Opening the windows start menu stops the shrinking. On the other hand, gedit shows only when I turn off opengl, but does not shrink (I can not minmize it) Seems to be a problem with the window manager in windows? Any ideas where to look? I tried xpra beta (4.0), both msi and exe setup files, etc. Over html5 everything works fine (except copy pasting does not always work). I do not have xming (or vcxsvr) installed. Despite some instructions on xpra I found via google, a windows xserver does not seem to be required? regards, Ivo From antoine at nagafix.co.uk Mon Oct 28 01:56:33 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 28 Oct 2019 08:56:33 +0700 Subject: [winswitch] Dancing windows on xpra windows 10 In-Reply-To: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> References: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> Message-ID: <4ae36fca-8148-763a-cb6a-29907124f16a@nagafix.co.uk> On 28/10/2019 02:09, Ivo Couckuyt via shifter-users wrote: > Hi all, > > I have some problems with xpra windows connecting to a xpra server on > ubuntu over tcp (both version 3.0.1). > > The gnome-terminal shrinks to 1x1 (titlebar only) and 'dances' to the > bottom of the screen (same for xterm so it is not a bug in gnome I > think). Opening the windows start menu stops the shrinking. Is this similar to this bug report? (includes a video) https://xpra.org/trac/ticket/2457 > On the other > hand, gedit shows only when I turn off opengl, but does not shrink (I > can not minmize it) Odd, is it not showing at all? Or is the window missing its contents? Could be this bug: https://xpra.org/trac/ticket/2462 (in which case, using a python2 server instead of python3 will fix things) > Seems to be a problem with the window manager in windows? Any ideas > where to look? I tried xpra beta (4.0), both msi and exe setup files, > etc. Over html5 everything works fine That's likely to be because the html5 client is more limited and does not implement all the features, in particular the window size constraints and desktop scaling. You can try disabling window size constraints by setting the variable XPRA_SET_SIZE_CONSTRAINTS=0 before starting xpra from the command line. To disable desktop scaling, use the command line argument: xpra --desktop-scaling=1 > (except copy pasting does not > always work). Browser support for accessing the clipboard is messy. More details here: https://xpra.org/trac/ticket/1844 > > I do not have xming (or vcxsvr) installed. Despite some instructions on > xpra I found via google, a windows xserver does not seem to be required? Correct. The Xpra client is a native application on all operating systems supported, including MacOS and MS Windows. An xserver installed on windows would not be used at all. Cheers, Antoine > > regards, > > Ivo > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From wssddc at wssddc.com Tue Oct 29 02:29:17 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Mon, 28 Oct 2019 22:29:17 -0400 Subject: [winswitch] Dancing windows on xpra windows 10 In-Reply-To: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> References: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> Message-ID: <3170132a-be23-dee3-2272-d9ff414b3df3@wssddc.com> Ivo Couckuyt via shifter-users wrote: > The gnome-terminal shrinks to 1x1 (titlebar only) and 'dances' to the bottom > of the screen I'm seeing the same thing with Windows 7 connecting to Fedora/KDE. But, it only triggers if I move or resize the xterm so I hadn't noticed before. Windows Xpra version 3.0.1.24232, 64-bit. From Ivo.Couckuyt at UGent.be Tue Oct 29 08:07:56 2019 From: Ivo.Couckuyt at UGent.be (Ivo Couckuyt (UGent-imec)) Date: Tue, 29 Oct 2019 08:07:56 +0000 Subject: [winswitch] Dancing windows on xpra windows 10 In-Reply-To: <3170132a-be23-dee3-2272-d9ff414b3df3@wssddc.com> References: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be>, <3170132a-be23-dee3-2272-d9ff414b3df3@wssddc.com> Message-ID: Hi, Yes, it is only triggered by moving, resizing, minimizing, and maximizing the window. The gnome-terminal does not open fullscreen so it is always a problem for me. It keeps shrinking and dancing but can be stopped by opening the windows start menu. Regards, Ivo ________________________________________ From: Bob Babcock [wssddc at wssddc.com] Sent: 29 October 2019 03:29 To: Ivo Couckuyt (UGent-imec); shifter-users at lists.devloop.org.uk Subject: Re: [winswitch] Dancing windows on xpra windows 10 Ivo Couckuyt via shifter-users wrote: > The gnome-terminal shrinks to 1x1 (titlebar only) and 'dances' to the bottom > of the screen I'm seeing the same thing with Windows 7 connecting to Fedora/KDE. But, it only triggers if I move or resize the xterm so I hadn't noticed before. Windows Xpra version 3.0.1.24232, 64-bit. From antoine at nagafix.co.uk Wed Oct 30 03:21:24 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 30 Oct 2019 10:21:24 +0700 Subject: [winswitch] Dancing windows on xpra windows 10 In-Reply-To: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> References: <9d83e25b-fd39-a03a-a61c-38fcdb4c8d90@ugent.be> Message-ID: <217a65ec-09f3-52c3-56f0-d2599f18749c@nagafix.co.uk> On 28/10/2019 02:09, Ivo Couckuyt via shifter-users wrote: > Hi all, > > I have some problems with xpra windows connecting to a xpra server on > ubuntu over tcp (both version 3.0.1). > > The gnome-terminal shrinks to 1x1 (titlebar only) and 'dances' to the > bottom of the screen (same for xterm so it is not a bug in gnome I > think). Opening the windows start menu stops the shrinking. On the other > hand, gedit shows only when I turn off opengl, but does not shrink (I > can not minmize it) I can now reproduce these two problems on one of my test systems. I do not know yet what has changed to break the OpenGL rendering, and I haven't had a chance to look into the "dancing window". The good news is that you can switch back to the Python2 / GTK2 builds to get going again, there are 3.0.2-RC builds here: https://www.xpra.org/beta/windows/ Sorry about the inconvenience. This is not something the automated tests can catch, and I tend to test MS Windows manually in a VirtualBox virtual machine which lacks OpenGL.. I'll try to do better next time. Cheers, Antoine > > Seems to be a problem with the window manager in windows? Any ideas > where to look? I tried xpra beta (4.0), both msi and exe setup files, > etc. Over html5 everything works fine (except copy pasting does not > always work). > > I do not have xming (or vcxsvr) installed. Despite some instructions on > xpra I found via google, a windows xserver does not seem to be required? > > regards, > > Ivo > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From wolfram.humann at gmail.com Wed Oct 30 15:14:40 2019 From: wolfram.humann at gmail.com (Wolfram Humann) Date: Wed, 30 Oct 2019 16:14:40 +0100 Subject: [winswitch] Beta problems Message-ID: Thanks for the clipboard fix ( https://lists.devloop.org.uk/pipermail/shifter-users/2019-October/002420.html). I upgraded my Win10 client to current beta (4.0 r24287) to get the benefits of the fix. Now the Maximize/Minimize/Close icons in the top right corner of of all xpra windows are replaced by some generic "window" icon. xterms shrink when moved so that only the titlebar remains. Some windows (e.g. the Eclipse "Select a workspace"-window) are clipped at the bottom so that some of their content is invisible. I thought that upgrading also the server (RHEL) might help. Got that to 3.0.1.r24293, but that didn't help. Downgraded the client to 3.0 r24039. Things are ok now. Best regards Wolfram From florian.feldhaus at gmail.com Wed Oct 30 16:14:20 2019 From: florian.feldhaus at gmail.com (Florian Feldhaus) Date: Wed, 30 Oct 2019 17:14:20 +0100 Subject: [winswitch] Running XPRA with headless GPU in docker container displaying via HTML5 client Message-ID: I have started creating a generic XPRA docker image which can be used to run any application and display it via the HTML5 client. It is in an early stage, but will likely become the basis of the popular Wireshark image and some other images I plan to create. You can find the current status here: https://cloud.docker.com/repository/docker/ffeldhaus/docker-xpra-html5 and the source here http://github.com/ffeldhaus/docker-xpra-html5 Now I'm trying to enable the container to use a GPU for OpenGL applications. That seems to be nearly impossible, at least if XPRA runs inside the container. I found a lot of examples which show how to run a container with headless GPUs and X11 including this one from NVIDIA: https://gitlab.com/nvidia/container-images/samples/blob/master/opengl/ubuntu16.04/turbovnc-virtualgl/Dockerfile But it seems that for all examples I found an X-Server in the Docker host is used (like in the example above). Here's my current take on it. This is the preparation (installation etc): https://github.com/ffeldhaus/docker-xpra-html5-opengl/blob/master/Dockerfile This is how the xorg config gets created with nvidia-xconfig and how xpra is started: https://github.com/ffeldhaus/docker-xpra-html5-opengl/blob/master/docker-entrypoint.sh I'm currently stuck with the following error but do not think this is the real issue: parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) As the docker container is running non-interactively, it does not have a tty0. Is this even possible or any idea how to make this work without X11 in the docker host? Here's the full output: [ 89356.122] Failed to rename log file "/tmp/Xorg.S21.log" to "/tmp/Xorg.S21.log": No such file or directory [ 89356.124] X.Org X Server 1.19.6 Release Date: 2017-12-20 [ 89356.124] X Protocol Version 11, Revision 0 [ 89356.125] Build Operating System: Linux 4.4.0-148-generic x86_64 Ubuntu [ 89356.125] Current Operating System: Linux xpra-opengl-69b979c464-kh6f8 4.14.138+ #1 SMP Tue Sep 3 02:58:08 PDT 2019 x86_64 [ 89356.125] Kernel command line: BOOT_IMAGE=/syslinux/vmlinuz.A init=/usr/lib/systemd/systemd boot=local rootwait ro noresume noswap loglevel=7 noinitrd console=ttyS0 vsyscall=emulate security=apparmor virtio_net.napi_tx=1 systemd.u nified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=true csm.disabled=1 dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 i915.modeset=1 cros_efi loadpin.enabled=0 lsm.module_locking=0 root=/dev /dm-0 "dm=1 vroot none ro 1,0 2539520 verity payload=PARTUUID=499BC516-64BA-734B-A677-3466FBD4DAF5 hashtree=PARTUUID=499BC516-64BA-734B-A677-3466FBD4DAF5 hashstart=2539520 alg=sha1 root_hexdigest=42c12623b5d6e222b2fb41afbb4b54cab96fa 5f5 salt=3d83dfa08b35b7df037d5654602ec193541bf632968f9fbf658df3df780f3d2c" [ 89356.126] Build Date: 03 June 2019 08:10:35AM [ 89356.126] xorg-server 2:1.19.6-1ubuntu4.3 (For technical support please see http://www.ubuntu.com/support) [ 89356.126] Current version of pixman: 0.34.0 [ 89356.126] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 89356.126] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 89356.127] (++) Log file: "/tmp/Xorg.S21.log", Time: Wed Oct 30 15:14:48 2019 [ 89356.127] (++) Using config file: "/etc/xpra/xorg.conf" [ 89356.127] (EE) Unable to locate/open config directory: "/run/user/0/xpra/xorg.conf.d/21" [ 89356.127] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 89356.137] (==) ServerLayout "Layout0" [ 89356.137] (**) |-->Screen "Screen0" (0) [ 89356.137] (**) | |-->Monitor "Monitor0" [ 89356.137] (**) | |-->Device "Device0" [ 89356.137] (**) | |-->GPUDevice "dummy_videocard" [ 89356.137] (**) |-->Input Device "Keyboard0" [ 89356.137] (**) |-->Input Device "Mouse0" [ 89356.137] (**) Option "DontVTSwitch" "true" [ 89356.137] (**) Option "AllowMouseOpenFail" "true" [ 89356.137] (**) Option "AutoAddDevices" "false" [ 89356.137] (**) Option "AutoEnableDevices" "false" [ 89356.137] (**) Not automatically adding devices [ 89356.137] (**) Not automatically enabling devices [ 89356.137] (==) Automatically adding GPU devices [ 89356.137] (==) Automatically binding GPU devices [ 89356.137] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 89356.137] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 89356.137] Entry deleted from font path. [ 89356.137] (==) FontPath set to: /usr/share/fonts/X11/misc, built-ins [ 89356.137] (==) ModulePath set to "/usr/lib/xorg/modules" [ 89356.137] (II) Loader magic: 0x5576a4975020 [ 89356.137] (II) Module ABI versions: [ 89356.137] X.Org ANSI C Emulation: 0.4 [ 89356.137] X.Org Video Driver: 23.0 [ 89356.137] X.Org XInput driver : 24.1 [ 89356.137] X.Org Server Extension : 10.0 [ 89356.138] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) [ 89356.140] (--) PCI: (0:0:4:0) 10de:102d:10de:106c rev 161, Mem @ 0xc0000000/16777216, 0x10000000000/17179869184, 0x10400000000/33554432, I/O @ 0x0000c000/128 [ 89356.140] (II) no primary bus or device found [ 89356.140] (II) LoadModule: "glx" [ 89356.140] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 89356.141] (II) Module glx: vendor="X.Org Foundation" [ 89356.141] compiled for 1.19.6, module version = 1.0.0 [ 89356.141] ABI class: X.Org Server Extension, version 10.0 [ 89356.141] (II) LoadModule: "nvidia" [ 89356.141] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so [ 89356.142] (II) Module nvidia: vendor="NVIDIA Corporation" [ 89356.142] compiled for 1.6.99.901, module version = 1.0.0 [ 89356.142] Module class: X.Org Video Driver [ 89356.142] (II) LoadModule: "dummy" [ 89356.142] (II) Loading /usr/lib/xorg/modules/drivers/dummy_drv.so [ 89356.142] (II) Module dummy: vendor="X.Org Foundation" [ 89356.142] compiled for 1.19.5, module version = 0.3.8 [ 89356.142] Module class: X.Org Video Driver [ 89356.142] ABI class: X.Org Video Driver, version 23.0 [ 89356.142] (II) LoadModule: "kbd" [ 89356.142] (WW) Warning, couldn't open module kbd [ 89356.142] (II) UnloadModule: "kbd" [ 89356.142] (II) Unloading kbd [ 89356.142] (EE) Failed to load module "kbd" (module does not exist, 0) [ 89356.142] (II) LoadModule: "mouse" [ 89356.143] (WW) Warning, couldn't open module mouse [ 89356.143] (II) UnloadModule: "mouse" [ 89356.143] (II) Unloading mouse [ 89356.143] (EE) Failed to load module "mouse" (module does not exist, 0) [ 89356.143] (II) NVIDIA dlloader X Driver 430.26 Tue Jun 4 17:52:10 CDT 2019 [ 89356.143] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs [ 89356.143] (II) DUMMY: Driver for Dummy chipsets: dummy [ 89356.143] (EE) Fatal server error: [ 89356.143] (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) [ 89356.143] (EE) [ 89356.143] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 89356.144] (EE) Please also check the log file at "/tmp/Xorg.S21.log" for additional information. [ 89356.144] (EE) [ 89356.144] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor [ 89356.144] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor [ 89356.144] (EE) Server terminated with error (1). Closing log file. From antoine at nagafix.co.uk Wed Oct 30 17:10:44 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 31 Oct 2019 00:10:44 +0700 Subject: [winswitch] Running XPRA with headless GPU in docker container displaying via HTML5 client In-Reply-To: References: Message-ID: <45db4213-2e53-2b08-d74a-3c4d7f3174a9@nagafix.co.uk> On 30/10/2019 23:14, Florian Feldhaus via shifter-users wrote: > I have started creating a generic XPRA docker image which can be used to > run any application and display it via the HTML5 client. It is in an early > stage, but will likely become the basis of the popular Wireshark image and > some other images I plan to create. You can find the current status here: > https://cloud.docker.com/repository/docker/ffeldhaus/docker-xpra-html5 > and the source here > http://github.com/ffeldhaus/docker-xpra-html5 There are a number of projects doing similar things. For example, you may want to look at: https://github.com/mviereck/x11docker > Now I'm trying to enable the container to use a GPU for OpenGL > applications. That seems to be nearly impossible, at least if XPRA runs > inside the container. I found a lot of examples which show how to run a > container with headless GPUs and X11 including this one from NVIDIA: > https://gitlab.com/nvidia/container-images/samples/blob/master/opengl/ubuntu16.04/turbovnc-virtualgl/Dockerfile x11docker does support it: https://github.com/mviereck/x11docker#gpu-hardware-acceleration > But it seems that for all examples I found an X-Server in the Docker host > is used (like in the example above). AFAIAA, that's currently unavoidable. > Here's my current take on it. This is the preparation (installation etc): > https://github.com/ffeldhaus/docker-xpra-html5-opengl/blob/master/Dockerfile > > This is how the xorg config gets created with nvidia-xconfig and how xpra > is started: > https://github.com/ffeldhaus/docker-xpra-html5-opengl/blob/master/docker-entrypoint.sh > > I'm currently stuck with the following error but do not think this is the > real issue: > parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) Not sure what's going on there. Ubuntu is known to apply Xorg patches that cause such problems. Or maybe Xdummy is finding the wrong Xorg binary. https://xpra.org/trac/wiki/Xdummy You may want to just switch to Xvfb instead of Xdummy. > As the docker container is running non-interactively, it does not have a > tty0. Is this even possible or any idea how to make this work without X11 > in the docker host? > > Here's the full output: (snip) Cheers, Antoine