[winswitch] Update for Xpra running Wireshark in Docker container

Florian Feldhaus florian.feldhaus at gmail.com
Mon Oct 14 17:00:24 BST 2019


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 <antoine at 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.

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 <http://xpra.org/trac/ticket/2444> for this.

>>> Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via
>>> shifter-users <shifter-users at lists.devloop.org.uk
>>> <mailto: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 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 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


More information about the shifter-users mailing list