How to install hyperland?

qubesosnewbie · April 28, 2024, 5:56pm

How to install hyprland ?

qubesosnewbie · April 28, 2024, 6:08pm

*hyprland

solene · April 28, 2024, 7:00pm

dom0 isn’t compatible with wayland. You could certainly install it, but the qubes won’t display.

qubesosnewbie · April 28, 2024, 7:24pm

It’s soooo sad same with bspwm??

qubesosnewbie · April 28, 2024, 7:25pm

Why not completable? There’s just no Wayland or other stuff?

apparatus · April 28, 2024, 7:38pm

github.com/QubesOS/qubes-issues

Wayland proxy compositor

opened 11:37PM - 29 Feb 24 UTC

DemiMarie

T: enhancement P: default C: Wayland

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## The problem you're addressing (if any) Qubes OS supports multiple desktop environments. It currently uses X11, which for all of its flaws is a battle-tested codebase. It will be switching to Wayland in the future as this is a requirement for GPU support. However, this makes the compositor responsible for what X11 did in the past. Furthermore, it removes the intermediate GUI daemon, which ensured that only valid actions reached X11. KDE uses KWin, which is written in C++. Sway (i3) replacement uses wlroots, which is written in C, and XFCE’s future Wayland support will also use wlroots. This means that the Wayland compositor is now attack surface in a memory unsafe language running with very high privilege. Furthermore, not all desktop environments Qubes OS supports are guaranteed to implement the security-context protocol, or to impose the correct restrictions when the protocol is used. This is a potential security problem. ### The solution you'd like Use a proxy compositor, written in Rust, that guarantees that only valid operations reach the main compositor. This compositor will use GPU rendering (via OpenGL or Vulkan) for high performance, and will skip copies when possible. ### The value to a user, and who that user might be Users will be able to use GPU acceleration. ### Design note This compositor **is not specific to Qubes OS**, though Qubes OS will be the initial user. The compositor should not call into Qubes OS-specific APIs directly. Instead, all such information (such as window borders) should be provided via a documented interface, either at startup or via IPC at runtime. Qubes OS will then implement this interface. By making the compositor independent of Qubes OS, multiple major advantages are obtained, in no particular order: 1. The compositor is **much easier to test**, and can be tested in VMs without nested virtualization. 2. The compositor is **much more broadly applicable**. For instance, it can be used by sandboxing solutions such as Flatpak, Snap, or Firejail. 3. The compositor is **much easier to get help with**, because one does not need to run Qubes to use it.

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.