[winswitch] Update for Xpra running Wireshark in Docker container

[Florian Feldhaus]

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 <shifter-users at lists.devloop.org.uk>:
> 
> 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 <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 <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 <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