mrxmr
October 30, 2025, 7:20pm
1
Reading the forum I can see that Whonix-18 is going to default to Wayland in LXQt. Is this also going to be the case for the Qubes-Whonix edition?
1 Like
Yes and no. We can’t use Wayland under Qubes OS R4.3 because all VM windows in Qubes are displayed via the GUI virtualization layer in Qubes, and currently that layer is X11-specific, thus we’re still using X11 there. However, we are replacing Xfce components in Qubes-Whonix with LXQt components.
Once Qubes OS gains support for Wayland and Wayland GUI virtualization, we will almost certainly be switching over to that.
2 Likes
Yes. There are zero blockers from Kicksecure, Whonix side. Once Qubes gains Wayland support, there’s probably little to do on the Kicksecure, Whonix side.
Related:
opened 05:47PM - 05 Dec 17 UTC
C: gui-virtualization
P: major
release notes
S: partial
bounty
fixed-by-wayland
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.
1 Like