-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Container applications running in Browser (without X server on the host) #110
Comments
I tried
Some of the applications in the launcher provided in
|
A lot of questions. :-) I'll try to answer them all soon. At least some points for now:
xfce is only partially ported to GTK3 yet, it's work in progress. Applications that still use GTK2 will fail. Many gnome application on the other hand are entirely based on GTK3 and are worth a try.
I assume html5 works like a video stream. The browser does not render the fonts itself and does not know what is text and what is not. However, that is not nice for productive use. |
No need to answer any of them fast ;).
I checked the repo of gtkwave and I found that there is a gtk3 branch indeed: https://sourceforge.net/p/gtkwave/code/HEAD/tree/. So, I built it again (https://github.com/ghdl/docker/blob/master/dockerfiles/ext/vunit#L36-L57) using that branch (I had to add a single new dependency:
Did you use the other option (with
I am not completely sure. Because you can copy text from a terminal and paste it to gedit. But only if both of them are in the html page. So there is some clipboard that is shared between all the apps connected to broadway. |
It could be an issue in gtkwave. Maybe it checks only
I only checked out the possibilities how to get it work, but did not use them. Note that xpra server on itself does not support GPU. It uses invisible X servers Xvfb or Xdummy to create a display. x11docker does some setup in background with hidden Weston and Xwayland and connects xpra to Xwayland. For the main purpose I think xpra is the most efficient way to run on a headless server.
For most setups it makes no difference. It takes effect e.g. with option |
Actually, gtkwave does it properly. It uses gdk_init_check, so it does not check ./x11docker -t -- \
-p=8080:8085 \
-e BROADWAY_DISPLAY=:5 \
-e GDK_BACKEND=broadway \
-- ghdl/ext:vunit-gtkwave "broadwayd :5 & sleep 2 && gtkwave"
That would be an option if I run the Earlier, I did execute
Agree. Nevertheless, since docker shares a directory between the host and the container, a file can be opened at the same time in both of them. This allows to work around the issue.
Can x11docker parse docker variables ( |
The command
You will need some helper anyway to provide a display. It can be VcXsrv or an xpra client or a VNC viewer or a browser.
I don't want to parse |
The command in the comment above fails after the fix for #112: ./x11docker -t -- \
-p=8080:8085 \
-e BROADWAY_DISPLAY=:5 \
-e GDK_BACKEND=broadway \
-- ghdl/ext:vunit-gtkwave bash -c "broadwayd :5 & sleep 2 && gtkwave" Also, if I add
Last, note that these examples don't work with
Agree. Rather than changing the entrypoint, I would add the script to
Sure. I will try with curl.
Even if performance is not the best, broadway works fairly well with gtkwave. That's what I wanted to test. Since libgtk-3-bin is already installed in the image, the benefit of this approach is that nothing but a browser is required. So, it allows to provide the demo of a environment for users that don't want or cannot spend time installing/configuring it. For example, currently this works: curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- -t -- -p=8080:8085 -e BROADWAY_DISPLAY=:5 -e GDK_BACKEND=broadway -- ghdl/ext:vunit-gtkwave bash -c "broadwayd :5 & sleep 2 && gtkwave" And it can/will be improved to: curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- -t -- -p=8085:8085 -e GDK_BACKEND=broadway -- ghdl/ext:vunit-gtkwave bash -c "gtkwave" Since x11docker shares a folder, this allows any user to try gtkwave with their own files. Just with a shell, docker and a browser. That's cool!
I will of course try xpra. I saw that there are lots of clients, as you commented. And I think that they can be used without admin privileges. However, unless the HTML option is used, SSH is required, isn't it? If so, I think that it is an interesting option for remote setups, but the effort might not be worth if/when VcXsrv is available. Personally, I don't like the VNC approach, nor installing SSH in the container. Hence, it'd be great if xpra could be used locally (i.e., exposing the ports to the host only) without requiring SSH. I'll investigate.
Understood. |
This is the script I am using to start broadway automatically: #!/bin/sh
# Example execution command:
# x11docker -it -- -e BROADWAY=5 -p 8085:8085 -- ghdl/ext:broadway bash
set -e
if [ "$BROADWAY" != "" ]; then
export BROADWAY_DISPLAY=":$BROADWAY"
if [ "$GDK_BACKEND" = "" ]; then
export GDK_BACKEND="broadway"
else
if [ "$(echo "$GDK_BACKEND" | grep "broadway")" == "" ]; then
export GDK_BACKEND="$GDK_BACKEND,broadway"
fi
fi
set +e; curl localhost:$((8080 + $BROADWAY)) > /dev/null 2>&1; err="$?"; set -e
if [ "$err" != "0" ]; then
echo "BROADWAY_DISPLAY: $BROADWAY_DISPLAY"
echo "GDK_BACKEND: $GDK_BACKEND"
# Start broadway server
broadwayd "$BROADWAY_DISPLAY" &
fi
fi
set +e It can be added to any existing image with FROM <image>
COPY broadway.sh /etc/x11docker/broadway.sh
RUN printf "\nsource /etc/x11docker/broadway.sh\n" >> /etc/bash.bashrc Alternatively, # Check if an instance of broadwayd is already running in the same port
lsof -Pi :$((8080 + $BROADWAY)) -sTCP:LISTEN -Fc | grep broadwayd Note that I did not need to work around EDIT I added the script above to some images ( x11docker -it --user=RETAIN -- -p 8086:8080 -e BROADWAY=5 -p 8085:8085 -- ghdl/ext:gtk-ide Then browse
Click the |
You can check
It avoids the issues shown in warnings of x11docker if using
I've added them to the wiki.
Wayland does not run natively on MS Windows. The wiki describes a nested setup within VcXsrv.
Xwayland is not officially supported by xpra, but works well. It supports GPU acceleration while Xvfb and Xdummy don't.
I did not compare it. Current Wayland desktops also run Xwayland for X clients, so there is still an X server. |
Thanks a lot, once again. I think we can close this. |
Correct.
I'm not sure I understand the context of this statement, but generally speaking no, see https://xpra.org/trac/wiki/Network |
@totaam, thanks for your comments. I just tried it today. Please, see a proof of concept in #117.
As you say, no, it is not. Since xpra is running in a docker container, I can bind it to a TCP port that is exposed on the host.
I tried |
I have zero experience trying to get mmap to work from a windows client to a container. Here I assume that windows and the container both have access to a filesystem that supports shared memory where you can create the mmap backing file. But that may not be the case... I don't know. |
At first, I thought that two files where required, one for the server and another one for the client. After these comments, I understand that it needs to be the same file. That can be a little more tricky because:
We are not using a socket for Moreover, I tried to use the |
Try
According to the xpra code, the mswindows code path should honour whatever mmap filename you tell it to use. (so I must have tested that at some point) |
Re: mmap file xpra server runs in a container in a Linux VM. xpra client runs on Windows. |
You're right. I was thinking of WSL, and shared-memory doesn't even work there yet: |
I think that all the questions in this issue have already being answered and we are moving slightly off-topic. I opened a new issue, #118, to continue the discussion about Some concluding remarks or summary:
@mviereck, it might worth adding a note to https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5 about the status of Broadway. |
First, some context. Since I use x11docker for development, I have focused on being able to use the same tools (containers) on different hosts (Win10, Fedora, Arch...). Precisely, I use x11docker to execute some GNU/Linux GUI apps on Win10. So, most of my comments are related to seamlessly adding
x11docker
to existingdocker run
commands, with minimum additional dependencies on the host: https://github.com/mviereck/x11docker/issues?utf8=%E2%9C%93&q=commenter%3A1138-4EB+Today, I was using it on a Fedora 29 host, which I think is using wayland. I installed
xpra
andnxagent
just to try them and I felt no difference. Then, I read https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#attributes-of-x-server-and-wayland-options. It seems that none of them support--gpu
, so I need--xpra-xwayland
if I want seamless mode and GPU support. This adds a bunch of dependencies (weston
,Xwayland
,xdotool
) on the host. Hence, I am considering if it is worth in my use case. @mviereck, could you explain in very few words which are the advantages of using--xpra-xwayland
instead of--hostdisplay
?What about
--gpu
support on Windows? IIRC (see #70), it is supported for seamless mode with either VcXsrv or Xwin. Should this be added to the wiki? I am not suggesting to do it. I wonder whether all the complexity about xpra, xephyr, wayland, etc. also applies to Win10 or it is somehow specific to GNU/Linux hosts. I found this page in the wiki: https://github.com/mviereck/x11docker/wiki/Wayland-on-MS-Windows. So, once again, is it worth using wayland on Windows instead of--hostdisplay
(which defaults to--vcxsrv
)?Overall, I feel that I can either use x11docker without worrying about settings as long as it works; or I need to know quite a lot about window servers and desktop environments. When I read all the available options, I wonder how do they compare according to complexity. I.e., does
--xpra-xwayland
run X apps on top of wayland with an X compatibility layer, which is connected through xpra to the Xorg server on the host? Does xpra replace the Xorg server on the host? Is it more performant to run wayland than an X server (i don't know, maybe because it handles resizing better) even if you are not using/developing an app that depends on it?@mviereck, I am not expecting you to answer all these last questions. Please, just drop some thoughts about it. If you have some list of references, I'd be glad to have a look.
Anyway, let's focus on the main topic. I was wondering which would be the approach to use x11docker in environments (clients) where no X server is available. I am thinking about Win10 setups without VcXsrv/Xwin or play-with-docker. This was asked in #80, which points to #40:
Does this mean that weston/xwayland running in a container can replace the server on the host? I can somehow imagine such a setup replacing vcxsrv and being able to draw windows on my desktop. But I cannot understand how would it work on play-with-docker, as I believe that the browser should not let me create random windows.
I checked https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#description-of-x-server-options:
On the one hand, why are these not used with
--gpu
? I assume that--weston-xwayland
is used. I.e., what does(X)
mean in https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#attributes-of-x-server-and-wayland-options? What about--kwin-xwayland
,--weston
or--kwin
, which support both--gpu
andconsole
?On the other hand, if I understand the scheme correctly, those are used in the server, so that applications running there believe that a display exists. Then, some client is connected to the server to actually render the windows. This is the case in the examples with SSH and xpra: https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra. However, this requires xpra to be installed on the client. I assume that xpra connects the server to the X server on the host/client. Hence, this does not really solve my issue.
Therefore, the last option is to use the browser to render the windows. This would work on almost any computer, because there are no dependencies at all besides docker (server) and a browser (client). I read Container applications running in Browser with HTML5. According to HTML5 with GTK3 broadway, I executed the example:
x11docker -t \ --env BROADWAY_DISPLAY=:5 \ --env GDK_BACKEND=broadway \ -- -p 8085:8085 -- \ x11docker/xfce "broadwayd :5 & sleep 2 && xfce4-terminal"
I get an error:
Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
. But I browsedlocalhost:8085
and it works fairly well.I wonder what's the difference between passing
--env
options to x11docker or putting them in the section for docker options. The following syntax works well too:x11docker -t -- \ -e BROADWAY_DISPLAY=:5 \ -e GDK_BACKEND=broadway \ -p 8085:8085 \ -- x11docker/xfce "broadwayd :5 & sleep 2 && xfce4-terminal"
Then, I tried to install something, but I couldn't. See #111.
So, I wrote a Dockerfile:
FROM x11docker/xfce RUN apt update -y && apt install -y gtkwave
I built it:
docker build -t broadway/gtkwave .
And I tried:
x11docker -t -- \ -e BROADWAY_DISPLAY=:5 \ -e GDK_BACKEND=broadway \ -p 8085:8085 \ -- broadway/gtkwave "broadwayd :5 & sleep 2 && xfce4-terminal"
I can start some GUI apps, such as another xfce4-terminal. But
gtkwave
refuses to start because:Some others that fail:
Cannot open display: .
:xfce4-about
,xfce4-appfinder
,xfce4-notes
,xfce4-keyboard-settings
,xfce4-panel
...startxfce4
fails becauseexec: xinit: not found
.Thunar: Failed to initialize Xfconf: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
.I get the same result if I try:
Note that I need to
exit
once, for the service to start.I tried interactive mode because I wanted to install
xterm
orxfce4-terminal
in the container. But, as reported in #111, I cannot install anything.Am I missing something? Why does xfce4-terminal work but not any of the other?
The text was updated successfully, but these errors were encountered: