great information in your post. nice pictures for clarity.
To clarify what I was saying, plymouth currently has the capability to “hijack” the uefi and to use the associated buffer. However, that capability may not be available in qubes due to the architecure design that incorporates a hypervisor and two separate instances of fedora running in virtual machines (AdminVM/Dom0 & GuiVM).
To go further down the rabbithole for clarification, plymouth is designed to work with Direct Rendor Management (DRM) Kernel Mode Setting (KMS) drivers. The basic strategy is to use the KMS drivers to set up an optimal native display “mode” that includes virtual terminals, buffers and allows a user space client direct access to graphics hardware. All this occurs prior to the root file system being mounted. Details:
Optimal Native Display “Mode”
The optimal display mode is enabled using kernel command line parameters that communicate with the KMS drivers, configure the initial RAM disk and enable user space features. The specific parameters are set by developers so they function with a specific linux distro. On my system, some kernel command line parameters are set in the bootloader files (e.g., Grub 2).
The Display Server
After the optimal native display “mode” is established, control of the virtual terminals and buffer content is handed over to plymouth. Plymouth, in turn, runs a display server that ultimately leads to what is displayed on the screen.
Of note, is that a given linux distro might use a specific display server spec (Wayland, X11) that operates in a different way from other servers. For example, Wayland specced display servers combine the display server and compositor and provide buffers for each client. X11 specced display servers, in contrast, include both a display server and separate compositor. In addition, the entire frame buffer is rendered by the compositor.
To make the architicture more complex, developers could use XWayland that allows an x11 specced display server within a Wayland client. I’m running fedora 36 on a Lenovo R400 and from what I can tell, it uses the XWayland option.
The Unique Qubes Architecture
Plymouth was initially designed around running a single “real” instance of Red Hat and fedora, though later adjusted for other linux distros running a single “real” instance.
Given that the qubes architecure runs a “real hypervisor,” along with two instances of fedora running in virtual machines (AdminVM, GuiVM), the developers task of configuring the use of the KMS drivers, kernel command line parameters and type/manner of the display server seems like a challenging task.
This challening architecture raises interesting questions for how exactly plymouth operates within the AdminVM and the extent to which plymouth interacts with the Xen Hypervisor and GuiVM, the processes they run and the resources they use (cpu, buffers etc.). It was my impression that these were the sorts of issues that @renehoj was referring to.
Update 2022.10.25 : I’m not certain that the plymouth can use Wayland spec for the display server. All instances of plymouth may use X11/xorg.