Are there plans to move to wayland?

jagnopurka · June 16, 2024, 6:45pm

Another concern I have for Qubes is its total reliance on Xorg. Xorg deprecation is progressing faster than most expected.

Is there work being done on migrating to Wayland?

solene · June 16, 2024, 6:49pm

Xorg in dom0 and within qubes are isolated from each other, that’s not really an issue even if Xorg is now considered obsolete.

alimirjamali · June 16, 2024, 6:51pm

I recommend you to read this issue on Github:

github.com/QubesOS/qubes-issues

Use Wayland instead of X11 to increase performance

opened 05:47PM - 05 Dec 17 UTC

artemist

T: enhancement C: gui-virtualization P: major release notes S: in progress bounty

Although this is not a security issue due to the guid security model, there are …several advantages to using Wayland instead of X11: ## Advantages ### Higher performance If allocations are on page boundaries, then we can use xc_map_foreign_rage (or the equivalent in the HAL) to map framebuffer pages directly from the client in the VM to the compositor in the guivm ### Lower memory usage Since framebuffers are mapped instead of copied, the proxy wayland compositor should use less memory than xorg (On a VM which currently has 800M of RAM and two windows, Xorg is using 1/6th of the physical memory) ### Easier GPU acceleration support AFAIR, a lot of OpenGL operations are preformed within the X server through the X OpenGL extensions. Simply forwarding these commands to the guivm would be dangerous, so we would need to process within the Xorg server then send the displaylist sometime before the end of processing and rendering. With Wayland graphics processing happens within the context of the application, and only a framebuffer is shared to the compositor. This means that we can simply attach GVT-g or comparable hardware graphics virtualuization to VMs without complex modifications to guid. ### Multiple dpi support Wayland allows one to attach multiple displays with different densities, which is important for people with HiDPI laptops who want to use external displays. We can simply forward events for screen update to the client, although we have to deal with anonymity for anon-whonix, where position of multiple displays could be very revealing. ## Method Wayland has two communication methods; Commands over a Unix socket, and shared memory buffers through a file descriptor with mmap. Commands, including shared memory setup and keyboard input, should be proxied through a client in the guivm and a stub compositor in the appvm. However, wl_shm::create_pool and wl_shm events should be intercepted so that the stub compositor and guivm wayland client both create file descriptors in their VMs, and the guivm maps a foreign range (or asks dom0 to do so, I'm not sure quite how that would work) to link together the contents of those two memory ranges. ## Doing this I am starting work on forwarding Wayland between VMs. I would be interested in working on this for Google Summer of Code if the Qubes project decides to join.

Then watch Qubes Summit 2023 talk by DemiMarie if you need more information (use a search Engine to find the video).

jagnopurka · June 23, 2024, 5:56pm

But if some app is Wayland only (like Waydroid), it won’t ever work on Qubes until it moves to Wayland, which in turn can support X apps just fine thanks to Xwayland.

Is there a guarantee that all new software will be backwards-compatible with X? I don’t think so. Currently almost all DEs still rely on X in some way (probably only GNOME really can run on pure Wayland), but in a few years this will almost definitely change.

apparatus · June 23, 2024, 6:08pm

It’s possible to run them with some workarounds:

jagnopurka · July 26, 2024, 10:30am

Do you believe it’s possible that new apps will more often then not start supporting exclusively Wayland, and X-only environments won’t be able to run them? Does it spell trouble if Qubes does not migrate soon enough?

solene · July 26, 2024, 2:24pm

GTK and QT programs will run on both for a while, no need to worry at the moment.