mirror of
https://gitlab.freedesktop.org/plymouth/plymouth.git
synced 2026-05-06 02:18:08 +02:00
read-only mirror of https://gitlab.freedesktop.org/plymouth/plymouth
When plymouth receives SIGTERM during shutdown or reboot, we must exit cleanly to avoid keeping files open on the rootfs and to avoid making drmModeSetCrtc () calls after the kms driver's shutdown method has ran. But at the same time we also want the boot-splash to stay up (in its idle form) until the system actually reboots or powers off. So we want to avoid the boot-splash getting replaced by e.g. the text-console. Add a plymouthd-fd-escrow helper which will get forked off when we receive a SIGTERM in reboot/shutdown mode with pixel-displays active. This helper will keep the fds for the pixel-displays open, so that the boot-splash stays up until the end. Changes by Hans de Goede: - Start the escrow helper from main.c instead of from the drm plugin - Rename the helper from plymouthd-drm-escrow to plymouthd-fd-escrow, since it will be used to escrow fbdev fd-s too now - In the child of the fork, continue with quiting normally (letting the bootsplash become idle) instead of exiting directly - Make plymouthd-fd-escrow a normal dynamic binary instead of a static binary, the initrd already contains dynamic binaries so it does not have to be static - Split the changes adding plymouth-switch-root-initramfs.service into a separate patch - Rewrite commit message Signed-off-by: Hans de Goede <hdegoede@redhat.com> |
||
|---|---|---|
| docs | ||
| images | ||
| po | ||
| scripts | ||
| src | ||
| systemd-units | ||
| themes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| acinclude.m4 | ||
| AUTHORS | ||
| autogen.sh | ||
| ChangeLog | ||
| configure.ac | ||
| COPYING | ||
| INSTALL | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| TODO | ||
plymouth - graphical boot animation and logger Plymouth is an application that runs very early in the boot process (even before the root filesystem is mounted!) that provides a graphical boot animation while the boot process happens in the background. 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. For systems that don't have DRM mode settings drivers, plymouth falls back to text mode (it can also use a legacy /dev/fb interface). In either text or graphics mode, the boot messages are completely occluded. After the root file system is mounted read-write, the messages are dumped to /var/log/boot.log. Also, the user can see the messages at any time during boot up by hitting the escape key. Plymouth isn't really designed to be built from source by end users. For it to work correctly, it needs integration with the distribution. Because it starts so early, it needs to be packed into the distribution's initial ram disk, and the distribution needs to poke plymouth to tell it how boot is progressing. plymouth ships with two binaries: /sbin/plymouthd and /bin/plymouth The first one, plymouthd, does all the heavy lifting. It logs the session and shows the splash screen. The second one, /bin/plymouth, is the control interface to plymouthd. It supports things like plymouth show-splash, or plymouth ask-for-password, which trigger the associated action in plymouthd. Plymouth supports various "splash" themes which are analogous to screensavers, but happen at boot time. There are several sample themes shipped with plymouth, but most distributions that use plymouth ship something customized for their distribution. Plymouth isn't done yet. It's still under active development, but is used in several popular distros already, including Fedora, Mandriva, Ubuntu and others. See the distributions page for more information. As with other projects hosted on freedesktop.org, Plymouth follows its Code of Conduct, based on the Contributor Covenant. Please conduct yourself in a respectful and civilized manner when using the above mailing lists, bug trackers, etc: https://www.freedesktop.org/wiki/CodeOfConduct