docker-for-win: provide an xvfb to xpra

[eine]

The same way x11docker/kaptain is used to execute x11docker-gui if kaptain is not available on the host, I suggest providing a image named x11docker/xvfb which contains only the required resources to run Xvfb and/or Xdummy. Then, use the container as a fallback when none of Xvfb, Xorg or Xdummy are available on the host.

On the one hand, as commented in #117, all xpra needs is an X11 server with the composite and damage extensions. So, by ensuring that x11docker is able to provide an Xvfb server, at least, recipes in the wiki can work on GNU/Linux, MSYS2, Cygwin, and WSL. Furthermore, it would allow binaries for Windows to be built with xpra server enabled (--use-display being forced to true).

On the other hand, it can also allow mode --xpra on any GNU/Linux server without X.

[mviereck]

I suggest providing a image named x11docker/xvfb which contains only the required resources to run Xvfb and/or Xdummy. Then, use the container as a fallback when none of Xvfb, Xorg or Xdummy are available on the host.

Sorry, I won't implement that. It adds a lot of complexity in x11docker but would be needed for edge cases only.
At least in WSL it is already possible to apply the wiki instructions for SSH and HTML5 with xpra.

[mviereck]

Just a thought: IIRC xpra contains an Xvfb server. If xpra server can be compiled on Windows and provides Xvfb on its own, it can provide it to x11docker. x11docker could use it with --hostdisplay.
E.g something like this could work:
xpra start :100 --start-child 'x11docker --hostdisplay imagename'
On Linux this setup works fine.

[eine]

I think that xpra does not contain Xvfb. Just as x11docker does, xpra is capable of starting an Xvfb, Xorg or Xdummy server, if the required dependencies are available in the environment. Precisely, xpra uses a wrapper named xpra_Xdummy: https://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy

NOTE: xpra_Xdummy is used in https://xpra.org/trac/browser/xpra/trunk/src/etc/xpra/conf.d/55_server_x11.conf.in, where %(xvfb_command) is replaced. xvfb_command is defined during setup: https://xpra.org/trac/browser/xpra/trunk/src/setup.py

Moreover, I think that this is why xpra server is not available in the GUI for windows:

So, that's why the setup I was thinking about is the opposite: use x11docker to provide a X server to xpra server. See #118 (comment). Certainly, I think that it should already be possible in either Cygwin or WSL, since xvfb is available. So this issue was a workaround for MSYS2 and hosts (servers) without X, or SBCs (such as RPi) with minimal setups. See also RancherOS.

@totaam, can you please confirm that xpra server is disabled on windows builds just because you assume that there will be no valid X server on a windows host? I.e., could xpra server work on windows if it was executed in Cygwin (where xvfb is available)?

[totaam]

Correct: you could theoretically run a seamless xpra server on mswindows if you could run an xvfb of any kind (either Xvfb or Xdummy).
I have seen patches for building X11 with MSYS2, so it should be doable: https://github.com/jtanx/fontforgebuilds

[mviereck]

Currently I see the following possibilities to provide an invisible X frame buffer to xpra:

• Using Xvfb and xpra server in WSL. That should already work ootb.
• A script that runs Xvfb in a container and provides it to xpra. (Not within code of x11docker as proposed above, but the script could use x11docker.)
• A native Xvfb.exe on Windows. Compare Xvfb in Cygwin docker-for-win: Xvfb in cygwin #123 and @totaam's proposal of building X11 with MSYS2. A custom Xvfb.exe would need maintaining, though.
• Using Xwin in Cygwin/X docker-for-win: containerized xpra server with xwin (cygwin) #122 and find a way to hide the Xwin windows. Maybe asking the developers for some sort of -hide option.
• Fixing the issues with VcXsrv and asking the developer for some sort of -hide option.

My favorite is VcXsrv. It is actively maintained and the developer gives friendly and helpful response.
It provides some sort of GPU acceleration (iglx). It can be used with MSYS2, Cygwin and WSL.
xpra might be able to use mmap because server and client could run together on the same system.
We could investigate the VcXsrv bug with xpra seen in #117 (comment) and ask the developer for help in fixing it.

[eine]

• Using Xvfb and xpra server in WSL. That should already work ootb.

I just tried and it does not work 😢. I installed xvfb, xpra and python-cryptography. xpra starts without relevant errors. But, when I open the client to connect to it I get:

[Errno 10061] No connection could be made because the target machine actively refused it

If I open a browser and visit localhost:8080, I get: disconnect: invalid packet format, not an xpra client?. So the xpra server is responding.

---

• A script that runs Xvfb in a container and provides it to xpra. (Not within code of x11docker as proposed above, but the script could use x11docker.)

How could the script use x11docker, without creating the X server with it? I'm really interested in a x11docker-friendly solution to this scheme.

---

• A native Xvfb.exe on Windows. Compare Xvfb in Cygwin docker-for-win: Xvfb in cygwin #123 and @totaam's proposal of building X11 with MSYS2. A custom Xvfb.exe would need maintaining, though.

What advantage would provide this compared to Xvfb in Cygwin?

---

• Using Xwin in Cygwin/X docker-for-win: containerized xpra server with xwin (cygwin) #122 and find a way to hide the Xwin windows. Maybe asking the developers for some sort of -hide option.

This should probably need some tweaks in xpra too, as xpra does not explicitly hide any window ATM: #122 (comment)

---

• Fixing the issues with VcXsrv and asking the developer for some sort of -hide option.

I'd use it if the issue is fixed, even without the -hide option. It is the only reasonable native alternative for MSYS2...

My favorite is VcXsrv. It is actively maintained and the developer gives friendly and helpful response.

We could investigate the VcXsrv bug with xpra seen in #117 (comment) and ask the developer for help in fixing it.

How do you reach him, tho? The tracker in sourceforge seems to have very little activity. Also https://github.com/ArcticaProject/vcxsrv#why-this-repo-and-these-builds-exist.

[totaam]

[Errno 10061] No connection could be made because the target machine actively refused it

9 times out of 10, that's a firewall blocking the connection.

If I open a browser and visit localhost:8080, I get: disconnect: invalid packet format, not an xpra client?

Is websockify missing?

What advantage would provide this compared to Xvfb in Cygwin?

Not requiring cygwin.

[mviereck]

How could the script use x11docker, without creating the X server with it?

An example is given in #125. I encounter an issue with xpra client, but that is probably a different issue. Setup of Xvfb and xpra server works.

[VcXsrv developer] How do you reach him, tho?

I once opened a bug ticket on sourceforge: https://sourceforge.net/p/vcxsrv/bugs/
The github repo is just an unmaintained fork.

[mviereck]

Feel free to re-open if this is of interest again.