Closed rosensvv closed 2 years ago
Are you launching from a container? In a non-container the only thing that is required to make XWayland work is to set the environment variable DISPLAY=:1
. If you are running in a container you need to use the additional mount points & environment variables like they are configured in the xterm docker-compose container. This is required so that your X11 application can talk to XWayland (which is essentially just an X11 display server).
If you want to launch applications on demand you need a way of telling your server to start the container or application. This can be done with a custom HTTP call from your browser & custom HTTP server implementation, or by using an existing (Wayland) application like a terminal or dedicated launcher. The drawback of the latter is that this won't work in a container unless you bundle all your apps in the same container as they need to be available on the PATH that your launcher uses.
My current setup is trying to launch anything from the alactritty container (after they have been installed of course) - it doesn't work, not even launching another alacritty terminal from the existing one (errors like: cannot open display, connection refused or no compositor listening). My other question is whether I can have the connect buttons on the demo-compositor launch specific containers (say one button launches the alacritty container and the other one launches the Xwayland environment container)
I'm not sure what the issue is. I can not reproduce it locally using docker compose. All ui applications installed in the Alacritty container work without issues if I include the additional X volume & environment variables. Tested apps including xterm, kwrite, firefox, alacritty itself etc.
Judging by the errors you describe, sounds like either environment variables are not set and/or volumes are not mounted that contain the unix socket which the apps use to connect to the compositor-proxy.
My alacritty docker compose section looks like this:
alacritty:
pid: 'service:compositor-proxy'
build:
context: example-apps/alacritty
dockerfile: Dockerfile
privileged: false
volumes:
- xdg-runtime-dir:/xdg-runtime-dir
- x11-unix:/tmp/.X11-unix
environment:
WAYLAND_DISPLAY: wayland-0
XAUTHORITY: /tmp/.X11-unix/Xauthority
XDG_RUNTIME_DIR: /xdg-runtime-dir
DISPLAY: ':1'
restart: always
I used the alacritty image in the example application directory, started it, ran su -
, and installed additional apps using apk add xterm firefox kwrite
. Exited root (so normal user again), and ran the installed apps. Tested kwrite with both kwrite
and kwrite -platform wayland
.
Most of the apps work now, not sure what changed, but I still have problems with pcmanfm. I thought that it comes with wayland support out of the box, but it says "Cannot open display:". I am worried that it's trying to use X and this brings me to my other concern, hence my second question: I don't mind making one container for both my wayland and X apps but I'm worried a lot of them will start in X mode by default. This is why I was wondering if I can make one of the buttons (in the demo compositor-module) start the Xorg container and have the other button start a wayland session, so they're always isolated.
I also tried pcmanfm-qt to the following errors:
QStandardPaths: runtime directory '/xdg-runtime-dir' is not owned by UID 1000, but a directory permissions 0777 owned by UID 0 GID 0
When ran as root:
QStandardPaths: wrong permissions on runtime directory /xdg-runtime-dir, 0777 instead of 0700
Could not open display
[1] 574 IOT instruction (core dumped) pcmanfm-qt -platform eglfs
After I chmod it to 0700 it just says Could not open display...
I switch to archlinux as the base distro for the environment, everything runs much faster and snappier now. I figured out that my problems are very much X-related: pcmanfm (or any gtk3 app) is started in X11 mode no matter what I do if the DISPLAY env. variable is set. This further reinforces my assumption that I need to isolate X and wayland in seperate containers...
You can do that, simply run an extra instance of the compositor-proxy on a different port. Make sure the adjust the config of the compositor-proxy to match this new port as well. I'll see if I can update the docker compose file to demonstrate this.
What about multitasking? Is there a way to switch between apps/minimize like a taskbar? I can only think of running another compositor that supports being run as a client, like sway, and then have that manage multiple open windows...
the compositor-module has an api to listen for and activate apps, but there is ne UI for it. This is to give users the liberty to design their UI themself and because it is out of scope (of what is already a big project).
I am trying to launch apps by simply installing them and launching them from the alacritty terminal. They all fail (tried to launch another alacritty, pcmanfm etc) with messages like cannot open display, connection refused or no compositor listening. What should be the workflow for installing and launching apps? What about Xwayland? Also can I have one of the buttons start an Xwayland session (I can see the xterm container is configured as such on the docker-compose, can I have them launch seperately rather than both launching at the same time?). Ideally I would want to install a wayland app launcher like rofi and have it launch other apps.