Is it possible to launch gnome-shell in nested mode as a Wayland “native” client (if client is even the right term)?
My desktop is GNOME Wayland. I’m trying to run a complete GNOME shell environment inside a systemd nspawn container and would prefer the setup to be end-to-end Wayland native. The end result I’m trying to achieve is a full “desktop-in-a-window”, similar to a VM with a display, yet running as a container. It’s my hope that the resulting desktop environment would have full graphics acceleration.
I think I have the appropriate things wired up to the container (wayland socket, dri devices, etc) and I’m able to successfully launch applications that can open windows on the host desktop. e.g., MOZ_ENABLE_WAYLAND=1 firefox.
The closest I can get to my ideal setup is launching Weston inside the container – its main window opens on the host desktop. I then can launch apps (e.g. Firefox) from the Weston terminal and the app windows appear inside the Weston main window. But Weston doesn’t provide a full shell experience (no task switcher, app launcher, etc) from what I can see.
Firefox, in both cases (direct and hosted within Weston) appear to have hardware acceleration. about:support shows details of my hosts GPU (Nvidia Quadro P620) and running some WebGL demos work. However, the frame rate in the Weston nested instance is significantly lower (about half), and the animation stutters.
Trying to launch gnome-shell --nested --wayland gives me:
libmutter-Message: 22:43:54.188: Running GNOME Shell (using mutter 43.4) as a Wayland display server
Failed to setup: Unable to open display, DISPLAY not set
… which implies that its looking for a X11 display.
I think I already know the answer to my question from looking at the Mutter source. create_nested_backend (meta-context-main.c:435) references META_TYPE_BACKEND_X11_NESTED, which I’m going to assume requires X11.
I started down the path of trying to forward the host Xwayland socket into the container, but hit some roadblocks. I decided that this was a good point to pause and post here. Wayland → Xwayland → Wayland seems like additional steps that could cause issues.
Did I overlook something? Some magic environment variable maybe?
Is implementing a NATIVE_NESTED backend something that’s on the roadmap? Or even a valid/possible idea? Something people would be interested in?
I’d tackle implementing this myself, but I first thought it a good idea to check if the work is being done somewhere, or the idea is totally crazy. I’m also not that familiar with Wayland internals, and thus I’d appreciate any pointers. My kick-off point was to dig into what META_TYPE_BACKEND_X11_NESTED is doing and try and go from there. It seems to use Clutter, which is apparently “archived”.
Thanks!