Endless Orange Week

Earlier this month, I participated in Endless Orange Week, a program where the entire Endless team engages in projects designed to grow our collective learning related to our skills, work and mission, while our ordinary work responsibilities and projects were put on pause.

I used the opportunity to refresh my memory of how our graphical boot splash animation is implemented, to understand the requirements and limitations so we can refresh it.

Our current boot splash animation was introduced with Endless OS 3.1.3:

Endless OS boot animation from versions 3.1.3 to 4.0.x.

For some background, the graphics that appear during the boot process of Endless OS are created by the following sequence of actions:

1. When the computer is turned on its firmware (aka BIOS) turns on the video card / screen etc and draws the manufacturer logo on screen; This happens before any piece of Endless OS has been loaded, and it is specific to each computer model / manufacturer. This image is also made available by the firmware to the OS via the BGRT ACPI table.
2. Our first stage bootloader (shim / fallback / GRUB’s 1st stage) is loaded and executed by the firmware, and makes its best effort to not draw anything on screen, preserving what has been drawn on the previous step.
3. The second stage bootloader (GRUB) is loaded and executed by the first stage, and in normal boots it again does not draw anything on screen. However, this is the point where the user can press ESC to show the boot menu (which is also automatically shown on dual-boot installations or if the previous boot failed). If the boot menu is shown, the screen is cleared to a blank black screen, and a text menu is drawn.
4. The Linux kernel is loaded by the second stage bootloader and draws the “fallback framebuffer” on screen, which by default is the manufacturer logo obtained via BGRT. On normal boots this is unnoticeable, since the screen is already showing that exact same image. But if the boot menu has been shown, the graphics flow will be OEM logo -> text boot menu -> OEM logo again.
5. The kernel loads the init program (systemd) which then starts all the different services needed to bring up the system’s userspace. One of the first services executed is Plymouth, which draws the boot splash animation on the screen and waits until the boot process finishes.
6. One of the last pieces started during the boot process is GDM, which is responsible for providing the user account selection screen and spawning a new user session upon login. Once GDM is loaded, Plymouth carefully hands-off control of the screen to GDM, and we make sure Plymouth’s boot splash animation, and GDM’s greeter background match, so the transition is smooth.

While our current animation looks pretty good, there are a few drawbacks with it (and with the overall graphical boot):

• This animation does not scale well on HiDPI screens: after scaling the logo would not be drawn from the edge of the screen.
• It does not support having a progress bar for when updates are being applied (which for us actually happen for some run-after-update jobs, not actual system-updates per se).
• While we hide the GRUB menu by default, when we do need to show it we use a text mode menu, and after the entry is selected the OEM logo gets displayed again.
• The boot splash animation background uses a different color than upstream GDM, which means for a smooth transition we have been carrying patches to change GDM’s background color. There is also a noisy texture to match GDM’s background upstream from when the animation was implemented, but that noisy texture has been dropped upstream and we missed dropping it from our boot splash animation. Oops!

Most of this project’s time was spent investigating and experimenting around Plymouth, the software used to implement the boot splash animation, or more specifically, in Plymouth’s two-step plugin. Plymouth does not have much documentation, but luckily the code is very well organized and easy to read, so the lack of documentation did not pose a real problem.

With that, I now have a clear understanding of the requirements and limitations for implementing a boot splash animation, so I can schedule some time with our designer and help her brainstorm a new boot animation for Endless OS 5.

I have also already reverted the background of our current boot splash and greeter to the upstream solid grey and changed our kernel configuration to disable drawing the OEM logo between the bootloader and boot splash, which are some small improvements we can do right away and help polish the graphical boot a bit more.
Finally, while looking into Plymouth, I submitted a change upstream that we have been carrying downstream for 6 years, and twofixes for typos in comments I found while reading through the source code. Once we have a new boot splash animation in place, I believe we will be able to drop downstream changes Plymouth, making one less package for us to maintain ourselves at Endless.

Advertisement