We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Flickerfree boot

Formale Metadaten

Titel
Flickerfree boot
Untertitel
Seamless boot for UEFI systems
Serientitel
Anzahl der Teile
561
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Presentation on the recent "flickerfree" boot work, where the goal is to go from the firmware splashscreen/logo to the GUI in one fluid experience without any modesets (causing the screen to blank) or transitions to text-mode. Topics discussed during the presentation are: The changes made to each of the involved components The upstream status of these changes Steps to take to enable this A typical UEFI boot of a Linux system looks like this: * firmware shows a boot logo * shim loads, clears the screen * grub loads, shows a text menu * kernel efifb loads, clears the screen, may show a bunch of text messages * kernel drm/kms driver loads * bootsplash (plymouth) loads * GUI loads Where the kms driver, plymouth and GUI load all may do a modeset resulting in the display loosing signal for a while. The constant screen clearing, various text-messages and the modesets all result in a quite restless boot experience. My latest project at Red Hat is fixing all this so that we go straight from the logo shown into the GUI, while still being able to show error messages at all stages if necessary. During this presentation I describe: * The changes made to each of the involved components * The upstream status of these changes * Steps to take to enable this Benefits to the eco-system: 1) A nicer boot experience for all Linux systems makes Linux more user-friendly and will hopefully lead to wider boot experience 2) Customized embedded systems can already offer a similar experience by disabling the kernel's fbcon driver. There are 2 downsides to the current solutions: 2.1) They are per project customizations, there is no standard way to do this, 2.2) Without fbcon, no text output is possible at all and if something causes the GUI to not load there is no way to show a message to the end user (who will not have serial console access). My work offers a standardized way to achieve the desired boot experience while keeping fbcon enabled so that error messages can be shown at any stage if necessary.