I installed sys-gui-gpu (I did the setup on two Qubes OS laptopts) by following the instructions, the result is that I got a sys-gui-gpu VM. After that, I need to stop lighdm on dom0 and start sys-gui-gpu from a tty, and I get into that VM lightdm where I can log in.
However, even after setting default_guivm to sys-gui-gpu, the VM can start other qubes but I can’t get any graphical window from them, the VM also can’t handle USB devices or networking like on dom0, and from there, I’m also stuck because I have no idea how to run commands on dom0 to manage the system.
So, I wonder if sys-gui-gpu is meant to be used as a regular App VM but with GPU acceleration, or if it’s meant to be used in place of dom0 GUI but in that case, it seems the salt formula still need work.
Right now sys-gui-gpu can be used only for security reasons to remove the graphics from dom0:
Furthermore, while in theory dom0 is isolated from the outside world, some graphical devices (e.g. displays connected via HDMI or DVI) offer two-way communication, which threatens this isolation and makes it harder to maintain. If a malicious device (rather than the user’s trusted monitor) were to be connected to one of these ports, it could inject data that could be processed inside of dom0. As long as graphical devices are in dom0, they also cannot be safely proxied to other domains. This is because the various solutions to multiplexing access to the GPU at the GPU/driver level (which would expose the “full” GPU to a VM) are orders of magnitude more complex than running display drivers in just one place. We consider this added complexity too risky to put it in dom0. Errors in the drivers could expose dom0 to an attack, and attacks on dom0 are the biggest threat to the Qubes security model.
There is a project to provide GPU acceleration to virtual machines, but it’s a WIP for now:
It seems that your sys-gui-gpu wasn’t configured correctly, maybe the salt formula is bugged.