By “known issues”, I meant issues the plymouth project has documented, or knows about.
Not necessarily what you’re experiencing, though I would mention I can run animations with higher resource demands than your theme, on bare metal fedora, without the issues you’ve mentioned, and my R400 is rockn’ an Intel Core2 T9400.
All the scripts I have tested have worked, what is it that doesn’t in Qubes?
I doubt the performance issues has anything to do with plymouth, it’s more likely the intel graphics.
I didn’t mean to sound critical or that I had the answers, I’m more here to learn and enjoy.
I’m not saying plymouth or Qubes themselves have known issues, rather the unique architecture for qubes that runs a hypervisor on bare metal and plymouth in a VM may be slowing things down.
For example, Qubes uses an older version of fedora that runs in a VM. Match that with plymouth running xorg (vs a Wayland speced compositor) and the hypervisor running on bare metal, and all the elements combined might run into some issues, including integrated graphics, as you mentioned.
–
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.
1 Like
I misunderstood your post, I thought you said you send the devs an email with bugs you found, but I guess you asked the devs if they knew of issues with qubes.
Plymouth doesn’t use xorg or wayland, it runs before the graphical interface is loaded. It uses the video hardware directly, I think it just uses framebuffer, which is I believe the performance issues are related to the intel driver or hardware.
Before plymouth is called, an optimal native video display mode is established using two kernel mode setting drivers that allow a client in user space direct access to the graphics hardware. This is the feature you mentioned.
However, when plymouthd (daemon) is called in the boot sequence, it takes over the optimal native video display mode, including the virtual terminal and drivers, and runs a display server (X11/xorg or Wayland/Wayland compositor) to write to the screen. I’m running bare metal fedora and it uses Wayland or XWayland. Its my understanding the current version of Qubes uses X11/xorg.
F.P. Murphy wrote a good article (see paragraph 3) that describes a lot of the technical details about plymouth, though some of the content is specific to early versions of plymouth.
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.
I don’t see how it matters if you use xorg or wayland, plymouth runs long before they are started.
The text you linked explains this, plymouth uses DRI or text mode framebuffer to show the graphics, and when x server eventually loads the mode is handled by the x server.
When the system boots, you use the kernel to access the vidoe hardware. It doesn’t matter which x server you use, once the boot is completed.
Thus very early on in the boot process the optimal native video display mode for the system is set by a kernel mode setting driver. In turn Plymouth uses that mode, and that mode remains the same during the entire boot process up to and after an X server starts. The X server, when started, takes over the existing mode, virtual terminals and framebuffer content.
Because [plymouth] starts so early in the boot process, it needs to be added to a distribution’s initrd (initial ram disk) and the distribution needs to interface with plymouthd to tell it how the boot is progressing. Furthermore the initramfs has to include all the necessary files needed by an X server.
One could argue that the first paragraph is a little vague, but the overall context of the article makes it clear that plymouth runs a display server to display to the screen and that server is loaded in the initrd/initramfs.
However, for systems without kernel modesetting drivers, there is a fallback text mode which is the familiar tricolor blue/white/black progress bar. Plymouth also drops back to this text mode if the default plugin fails for whatever reason.
Text mode comes into play as a default. The display server that plymouth uses accesses the frame buffer, with the specifics being different between the Wayland and X11 spec.
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.
Feel free to point out where the x server is, I’m too stupid to find it.
It is designed to work on systems with DRM modesetting drivers. The idea is that early on in the boot process the native mode for the computer is set, plymouth uses that mode, and that mode stays throughout the entire boot process up to and after X starts. Ideally, the goal is to get rid of all flicker during startup.
As a caveate, I’m an organizational psychologist doing documentation on plymouth. I understand things on a systems-design level, but getting down to the source file configuration and details like initramfs is challenging. That said, the GitLab freedesktop.org/plymouth instance is consolidating all the available information on plymouth into their wiki, including the early implementation (fedora 10,11) file structure. X11 is listed in the src/plugins/renders space.
How exactly the server takes over the native optimal video display is getting into a realm I don’t fully understand, and rely on the developers for help. That said:
-
X11 is referenced in the plymouth spec. plymouth/scripts/plymouth.spec
-
X11 is referenced in the plugin files. plymouth/src/plugins/renderers
-
The plymouth daemon (plymouthd) - plymouthd is one of two binaries. Its called during the initrd process and controls the display server. Its located on the device at /sbin/plymouthd. The Murphy article has a lot of great information, but theres a lot of information. If you search the article for “plymouthd” you’ll find mention of the binaries and the purpose of plymouthd.
As I said, I’m not a developer, just doing some documentation. The above is about the extent of what I understand.
.
This is true. So you’d essentially be limited to Fedora 32 “stuff” unless you wanted to get hacky.
Well, might I say that that’s some mighty fine documentation. Very comprehensive 
But @renehoj does seem to be right in the sense that plymouth doesn’t actually “use” X or Wayland, because it’s doesn’t actually need to.
In actual fact, plymouth never ceases the entire time the machine is on. That’s why it’s important to have the plymouth daemon running at all times, so it can talk to the initramfs process at all times.
In the past, what ended up happening was that each stage of the boot process was isolated, and didn’t share the same framebuffer. That’s why computers when we were younger would go through multiple resolution changes every time it booted (we all remember the screen flash between the profress bar and the login screen).
From what it looks like, there has been a tremendous amount of collaborative work done with the codebases of bootloaders, plymouth and display managers to kind of allow the already initialised and set up display to be grabbed/claimed by the next stage of the boot process, eliminating the need to
Those unnecessary display resets (which made an audible crackle on CRT monitors 
).
I have a feeling that this is what @Jim is referring to.
If this is the case, then this won’t be possible in Qubes OS, in some cases could be a massive security risk if you don’t reset the GPU before passing it into dom0.
But there would definitely be a way for you to get that performance for your boot splash you want, even under Xen.
1 Like
Thanks for the props.
I may been wrong on the use of a Wayland speced compositor, but I’m fairly certain that a display server is used by plymouth, with the display server files (X11/xorg) being loaded in the initrd/initramfs. The DRMKMS drivers set up the optimal display mode, but the mode is then used by plymouth to run the display server. You have more hands on experience, so if you have theory, I’d be glad to hear it.
I’m not certain about this, though I will say you can restart the plymouth daemon (plymouth hd) after the system is booted. In the Murphy article, he mentions plymouth quitting at the end of the boot cycle:
So how does Plymouth know when to quit? Actually, it has no way of knowing. It just keeps on going until it receives a quit message. In the case of Fedora 11, the /etc/event.d/quit-plymouth script sends the quit message.
# quit-plymouth - script to stop boot splash
#
# This service triggers plymouth to quit when we reach the
# end of the boot cycle. We start on 'stopping rcX' to make sure
# this completes before the getty starts.
# prefdm handles quit differently, though.
start on runlevel S
start on stopping rc2
start on stopping rc3
start on stopping rc4
script
/usr/bin/plymouth quit || :
end script
The Murphy article is a tough read, lots of information and a small font. However, it is probably the most comprehensive article I’ve found on how plymouth operates, especially during the boot process, though written for the initial releases of plymouth.
Follow up to prior post…
Red Hat Graphical Boot was the predecessor to plymouth that had issues in that “the sequence of switching from text mode to rhgb ‘s X server to text mode to the display manager’s X server can cause significant screen flickering.” RHGB, operation according to Murphy (second paragraph:
As can be seen, rhgb uses an X server, though that doesn’t mean that plymouth has to. My understnding is that the workings of plymouth are similar, though the flicker issue is addessed by Direct Rendering that allows the X server “direct” access to graphics hardware via the Direct Render Managemen Kernel Mode Setting drivers. This setup reduces conflicts with other programs by moving graphics device configuration and modesetting into the kernel.
While I’m unclear on the specifics, it’s my understanding the plymouth layout is somewhat similar to RHGB, the key difference being the use of direct rendering (the blue line in the diagram):
updated titles for plymouthd and plymouth (control interface). 20221031 updated with DRI3 spec.
The plymouth diagram is a work in progress, shown to illustrate my understanding of the key difference between RHGB and plymouth. I’m trying to find more information to ensure the rest of the elements and links in the diagram are correct.
1 Like
Nice diagram, but where in the code is the x server?
I’m not sure what you mean, can you clarify? If by code in source files, then the links below are what I know. The plymouthd binary, that controls the X server, and the X11 plugins both have what I’d consider to be code.
But isn’t the plugin just the render that what allows you to debug/develop plymouth scripts in x11?
Where is the X11 code used in the boot process?
To be honest, I don’t know. Plymouth does do some debugging with X11, so that could be the plugin. You can also run a plymouth theme without rebooting via the X11 plugin, so the plugin may not be proof positive of the X server being used to paint the animations to the screen.
I’m not sure about the binary (plymouthhd), its supposed to control the X server.
My understanding is that the X11 spec (xorg implementation) is used during the boot process to paint the animations to the screen. I’d mention that Murphy shows a “nash script” (search the page for “lsinitrd /boot/initrd-2.6.29.5-191.fc11.x86_64.img”) that is supposed to load the files needed by the X server. My thought was those were used by plymouth for painting the screen. The kernel drivers set the mode and configuration for the hardware, but the X server handles the display.
I think the x server is needed for compositing, rendering and painting to the screen. How do you think that happens?
plymouthd is main program that does all the work, plymouth is just a program that interfaces with plymouthd.
You don’t need the x server to draw on the screen, you just need a driver that allows you to use the video hardware.
1 Like
This explains the basic of the transition from plymouth to the x server
1 Like
Yes, plymouthd (daemon) is one of two binaries, the other being plymouth (the plymouth control interface) that can send commands to plymouthd. “plymouth” is also used as the name for the overall program/process/group of source files.
How does the driver / hardware do the compositing, rendering and manage the buffer?
I think the Ray Strode article is using “plymouth” to refer to the collection of files / process, not plymouth as a control interface.
In terms of the “transition”, as the Murphy article said, there is a sequence of “transitions” - "switching from “text mode to rhgb ‘s X server to text mode to the display manager’s X server can cause significant screen flickering.” That’s three transitions: 1. text mode to RHGB X server, 2. RHGB X server to text mode and 3. Text mode to the Display Managers X server.
I think the Ray Strode article is referring to how the plymouth X-server instance is transitioning to the display manager X-server instance, he just lumps everything together that’s occuring withn the “plymouth overall process”, including the plymouth X server, under one name.
If I said “controlled” then I may not have been precise. As far as I know, plymouthd starts the X server and sets up the “minimal” environment for its server and compositor to operate. Much of the processing and “control” then occurs through the process where boot scripts communicate to plymouthd via the control interface.
I’ve been trying to track down the uncompiled plymouthd file, but no luck. I did find main.c that contains the initialize_environment function that calls the plugin renderers/x11.so. Since this function takes into account the different “modes” (boot, shutdown, reboot), I’m thinking this is more than just for debugging. A look at X11/plugin.c seems very involved with rendering, buffers and gtk.
I’m still learning about C coding, but the src/Makefile.am code looks like it compiles `plymouthd’ and includes main.c, mentioned above, the other compiled code involves setting up the X server during bootup.
plymouthd_LDADD = $(PLYMOUTH_LIBS) libply/libply.la libply-splash-core/libply-splash-core.la
plymouthd_SOURCES =
ply-boot-protocol.h
ply-boot-server.h
ply-boot-server.c
plugins/splash/details/plugin.c
main.c
Just a quick follow up to update what I found on plymouth and Direct Rendering Infrastructure. The model from my upstream post is my current “theory” on how plymouth operates, though there are likely issues with it at this point. I think you and @alzer89 brought up valid arguements regarding the model itself. My understanding:
@renehoj
1. If its not needed, its not in plymouth: Its hard to argue with that. If the X server isn’t needed for plymouth to operate, then it won’t be used by plymouth.
2. If its not in the code, it doesn’t exist: This makes sense, as well. If plymouth uses an X server, then there should be code to envoke and support it.
@alzer89
1. Plymouth should be aligned with the boot process: Since plymouth operates during the boot process, it should be called and referenced during the boot process. This a good point, and any understanding of how plymouth operates should be consistent with the boot sequence.
2. Plymouth may react differently to different architectures: Since plymouth operates within a larger architecture (e.g., bare metal fedora, qubes fedora on a VM) the architecture itself could impact plymouth’s performance (aka, resource constraints).
These are all great points that I’ve been trying to follow-up on. In terms of whether or not the X server is needed at all: it looks like the answer could be a qualified “yes”, though certain key functions performed by the X server have been moved to the linux kernel (Kernel Mode Setting Direct Rendering Management drivers) and X11 extensions have been created to enhance the effectiveness of the X server.
-
Direct Rendering Infrastructure: one of the original objectives of plymouth was to take advantage of DRI, including the use of the DRMKMS drivers. This would eliminate the bottle neck created through inter-process communication overhwhelming the X server. This would be achieved by moving features/functions within the X server (e.g., graphics drivers) to the linux kernel.
-
DRI2 / DRI3 extensions: Although features/functions of the X server were moved to the linux kernel, the X server remained in place, though its capabilities were expanded. For example, X server client’s (DRI clients) could connect directly with shared graphics driver libraries and the kernel’s DRM driver. In addition, each X server client (DRI client) gets its own back-buffer. The X server is still used as it manages the life-cycle of the render buffers.
I’m in the process of tracking down where this is all mentioned in the code and how it relates to the boot sequence.
1 Like