* We need to update GDM to use those option. One problem with this is, we only want to use the vt7 option for the login greeter. We don't want it for user switching greeters. It's tempting to turn on factory mode in the GDM source code and just make the factory X server use vt7 while all other non-factory greeters wouldn't get it.

* We need to update GDM to use those option. One problem with this is, we only want to use the vt7 option for the login greeter. We don't want it for user switching greeters. It's tempting to turn on factory mode in the GDM source code and just make the factory X server use vt7 while all other non-factory greeters wouldn't get it.

* We need to update GDM to not set it's background, and instead just use what was shown during plymouth

* We need to update GDM to not set it's background, and instead just use what was shown during plymouth

−

* Turn on silent grub mode. We have all the bits in rawhide. We just need to adjust the default config to use a timeout of 0.

* Make sure grub patch works with efi, too. This would probably have to be either Peter or krh, since Peter knows about EFI, krh wrote the silent patch for legacy bioses, and both have efi hardware. Peter is planning on moving grub over to an efi library, so this should block on that.

* Make sure grub patch works with efi, too. This would probably have to be either Peter or krh, since Peter knows about EFI, krh wrote the silent patch for legacy bioses, and both have efi hardware. Peter is planning on moving grub over to an efi library, so this should block on that.

* Make sure grub patch doesn't mess up multi-os environments. See bug 458576. In particular we should probably add a new chain loader timeout config option with a reasonably high value (say 30 seconds) and use that timeout if there are any items in the configuration that chain load. The idea being we should always show the menu in that case.

* Make sure grub patch doesn't mess up multi-os environments. See bug 458576. In particular we should probably add a new chain loader timeout config option with a reasonably high value (say 30 seconds) and use that timeout if there are any items in the configuration that chain load. The idea being we should always show the menu in that case.

Better Startup Experience (Graphical Boot Sequence)

Summary

The startup experience needs to be flicker-free, seamless and shiny. To do this we are getting rid of RHGB and writing a new program, Plymouth, that starts earlier (even before / is mounted!), doesn't require an X server, and gets rid of a lot of the noise during startup.

Plymouth will requires DRM kernel modesetting drivers to get pretty graphics, but will have a text mode fallback for systems without driver support.

Owner

Current status

Targeted release: Fedora 10

Last updated: 2008-07-31

Percentage of completion: 53%

F9 had kernel modesetting for Intel hardware.
Ray has been working on a prototype rhgb replacement called Plymouth. It was put on hold while kernel modesetting was maturing, and has been revived after F9. Modesetting is again in flux, though, in rawhide, since there are two memory managers in play. These are the long anticipated TTM memory manager from tungsten graphics, and the newer GEM memory manager from Eric Anholt at Intel that supercedes TTM. Intel is currently targeting working Intel kernel modesetting driver on top of GEM by F10.

ATI recently released a kernel side atom parser to make radeon kernel modesetting (at least for r500 and higher) possible. Dave Airlie uses that parser to provide a GEM like api on top of the existing work that uses the TTM memory manager. Hopefully we'll have kernel modesetting for some ATI hardware by F10.

The current plymouth sources can be found here: http://gitweb.freedesktop.org/?p=plymouth;a=summary . There are plymouth packages in rawhide already, modesetting drivers, aren't, so most people won't be able to see graphical boot up yet. Having said that, we enable the text plugin by default now. Anyone using rawhide will see it, although it's sort of ugly and flickery. Live images now also run plymouth in their initrd.

The new startup sequence (including quiet kernel,
quiet grub, plymouth, smooth transition to the login screen) has been demonstrated at the Red Hat Summit
and was shown informally to various people at FUDcon.

Scope

Requires changes to grub, mkinitrd, initscripts, gdm, X, possibly other packages. rhgb will be replaced by Plymouth. The extent of this project is getting a graphical boot sequence that is polished and professional looking.

Boot up could be made faster, too, but that issue is orthogonal and should be tracked separately .

Test Plan

Verify that holding a key during power-on gets you to the grub menu

Verify that boot without rhgb in the kernel cmdline gives a traditional text mode boot sequence

Verify that failure to set a mode in initrd falls back to a clean and simple text mode boot sequence

Verify that the graphical boot sequence contains only a single mode switch from blank text mode to graphical mode, and that there is a smooth transition from the startup animation to the login screen

Verify that entering encryption passwords works both in the graphical case and in the fallback case

Verify that specifying a mode in the kernel commandline works

Verify that failure messages from service startup can inspected after boot

Verify that dropping to a shell on critical errors works

Verify that pressing Escape in plymouth brings you to the detailed mode showing boot messages

Dependencies

This feature depends on plymouth getting into F10. For other packages involved in realizing this feature, see Scope.

Details

For a smooth and shiny experience, we want

the mode should be changed early from text mode to the most optimal graphics mode available

the mode should not be changed more than once

there should be no other uncontrolled transitions

there should be no text messages, unless the user presses Escape to see them

there should be good, smooth transitions

The fallback if mode-setting fails or is unavailable is text mode.

Timeline of the current bootup

bios

text

grub

graphical

grub info

4>text

kernel boot

initrd drivers

init

rhgb

graphical

text login

text

gdm

3>graphical

gnome startup

user session

Plan for improving this

do away with mode switch for grub menu by default (ie, don't show the image unless "needed")

This is in rawhide now, but the default configuration isn't making use of it.

make kernel, nash and init obey the quiet option

There are patches for these, though the kernel keeps sneaking messages in.

switch to graphical mode in the initrd, draw an animation and keep it running until gdm starts up

We have an animation but need there are some changes we need to make to the X server and GDM to keep the transitions smooth

rhgb goes away

rhgb is already gone

make the X server started by gdm take over the existing vt, mode and framebuffer content

krh has a patch which adds a -nr ("no root") option which makes the root window keep the framebuffer contents that were around when X started

improve the transitions animation -> gdm -> session

firstboot runs on the gdm X server

This lets us start with a blank screen in text mode, then a single switch to graphics mode,
then an animation, then the login screen fades in.

bios

3>text

grub

kernel boot

initrd drivers

5>graphical

init

gdm

gnome startup

user session

One complication is support for encrypted disks. This may require us to ask for a password in the initrd, before we have X or toolkits. The proposal for acceptable input-handling (at least as far as keyboard layouts are concerned) is to write an xkb-to-console-converter.

Tasks

Make grub not display a splash image unless the user holds down ctrl to get to a menu. Grub will have a near zero timeout, but users will be able to hold the key down at the bios before grub shows up.

Make grub not report which choice was selected if the user didn't pick a choice #239760

For selecting the mode, make s-c-d set a kernel commandline like rhgb:mode=1600x1200 or similiar

Open question: what about multihead ? answer for now: all heads painted in background color except one chosen randomly with animation

Display animation all the way from initrd until gdm comes up, keep initrd mounted until it exits

Redirect init output early on to a pseudo-terminal

Have something that buffers the output, can buffer it on the initrd

If something happens that drops us to a shell (filesystem errors), hook up a framebuffer console with the pseudo-terminal

If there are warnings in the saved bootup messages, show a "Show boot messages" button on the login screen and/or in the notification area

Need to start X on the existing vt, not set mode (unless we are still in text mode), preserve existing framebuffer content

Coordinate session startup. fade in ? might be able to do something nice if we have compositing

TODO

krh to get GEM in rawhide. GEM is a key component to getting shared graphics between X and plymouth.

This requires:

Updating the kernel. We need to update the drm module shipped in the kernel with the drm that ships in the gem-modesetting branch of Mesa.

Update libdrm. We need to update the libdrm userspace interface to the kernel module again from the gem-modesetting branch of Mesa.

We need to update the X server intel dri driver from gem-modesetting branch.

This will have to wait until it works better. Eric Anholt and Keith Packard are working on it at Intel.

rc.sysinit also needs to use plymouth ask-for-password when it asks for passwords. Bill is looking into this. It's for unlocking auxillary devices like encrypted /home partitions. One complication with these auxillary devices is we need to let the user know which device it is. Plymouth currently has no way of doing that. This leads to two prerequisite TODOS:

We need to make plymouth support font rendering after root fs is mounted, so auxillary encrypted block devices can have a prompt string. At a minimum we should have limited ascii support, but we probably want to dlopen pango/cairo and draw text to an image surface that's copied over to the framebuffer. This could all happen as an implementation detail in a new ply-text.c. If we're going to be using cairo *anyway* though, we may want to consider shipping it in the initrd and making a stock feature for splash plugins to use. Hard to say what's right. It's a bit of a slippery slope, because if we gain a cairo dependency in the initrd then we'll also gain a pixman dependency which could give us cpu accelerated pixel conversion operations when going from the shadow buffer to the scanout buffer.

We need to add a -hidecursor (ajax already has a patch from someone and will be merging it upstream soon). The idea is we don't want to show an "x" cursor when X first starts before GDM loads, then GDM will need to call XFixesShowCursor at startup to bring the cursor into being.

We need to add a -nr (don't clear frontbuffer, krh has a patch) options to X to make the transition from plymouth to X smoother.

We need to add a vt7 argument to the X server so X starts on vt7 even though that vt is already open from plymouth

We need to update GDM to use those option. One problem with this is, we only want to use the vt7 option for the login greeter. We don't want it for user switching greeters. It's tempting to turn on factory mode in the GDM source code and just make the factory X server use vt7 while all other non-factory greeters wouldn't get it.

We need to update GDM to not set it's background, and instead just use what was shown during plymouth

Make sure grub patch works with efi, too. This would probably have to be either Peter or krh, since Peter knows about EFI, krh wrote the silent patch for legacy bioses, and both have efi hardware. Peter is planning on moving grub over to an efi library, so this should block on that.

Make sure grub patch doesn't mess up multi-os environments. See bug 458576. In particular we should probably add a new chain loader timeout config option with a reasonably high value (say 30 seconds) and use that timeout if there are any items in the configuration that chain load. The idea being we should always show the menu in that case.

Need to run art by fedora-art-list for opinions and potential changes. They may have some useful suggestions on making the process more polished.

Need to figure out what to do on shutdown. This probably means having a plymouth client command to activate the daemon and show splash

Need to figure out what to do on wake up from hibernate. When coming out of hibernate we'll get a brief period where we can show animation, but we need to end on a still image. We need to make sure the kernel doesn't clear that still image if possible. That might be tricky.

Right now we get events about boot from the legacy init scripts. Might be nice to get events in a more upstart friendly way. The latest upstream upstart gives limited events as jobs start, finish starting, and stop.

Might be good to detect a failure during boot up and show it to the user at the login screen via a notification area icon. Right now on failure rhgb-client --details=yes is called which is a noop. One idea is to make it hard link /var/log/boot.log to /var/spool/somewhere/something . Then there would be a small app that is started in the greeter via /usr/share/gdm/autostart/LoginWindow that would look at the spool directory on startup, read any file that's there into memory, remove it from the spool directory and display an icon in gdm's notification area. If the icon gets clicked on the program would display a little vte widget with the buffered boot log. Done - Matthias has a little program which parses boot log and shows a statusicon, it just needs integration into plymouth/gdm.

Investigate why kernel messages are no longer getting redirected to boot.log and instead overwriting text plugin. Kernel messages go to the current active console which should be a pty plymouth owns. Bill mentioned the other day he saw kernel messages on top of the text plugin which shouldn't happen. Maybe upstart is calling the TIOCCONS breaking us.

plymouth needs to be ported to use libdrm api for modesetting. It currently uses standard kernel ioctls on /dev/fb for getting a front buffer to render to. By using libdrm we'll be able to set the mode intellibly in multihead environments, place X's mouse cursor off center before X is even started, etc. With the exception of the mouse cursor bits, we probably won't get to this until F11.

This api is still in flux, though. It's important we use the API exported by the gem branch. This should happen almost entirely in ply-frame-buffer.c.

The old vesafb interface should remain as a fallback. Ultimately, either api will end up with a block of memory that is the scan out buffer that goes to the screen. Either api will keep the shadow buffer code there that's in a well known format. At flush time that shadow buffer is converted into a format that's compatible with the scanout buffer.

There is some question on if the kernel will do the right thing wrt to fbcon if plymouth allocates the frame buffer instead of letting the kernel do it.

Any cursor setting api logically belongs in ply-window.c, but the logistics may make that hard. If we hide vesafb versus drm modesetting entirely in ply-frame-buffer.c, and cursor setting only works with drm modesetting, then we'll need to provide some sort of hook from ply-frame-buffer (say ply_frame_buffer_set_cursor_position). It might make sense to have a wrapper api in ply-window that just calls the frame buffer api, or maybe just have splash plugins use the frame buffer api directly. Once the cursor setting api is in place, we should make sure the cursor gets moved below the logo on screen in splash plugin and make sure that the X server doesn't recenter the cursor when it starts.

Contingency Plan

If things don't work out as expected, we can bring back rhgb from the dead.

Documentation

While plymouth won't need much in terms of end-user documentation, we eventually need to have developer documentation for

Release Notes

The release notes need to explain how to get to the grub menu by holding a key during power-on. Should also explain that the graphical mode of plymouth requires kernel modesetting and will only work on certain hardware (likely only intel for F10), or by forcing a vga mode on the kernel cmdline. Also, switching to detailed mode with Escape should be mentioned, along with the fact that boot warnings will be available via a statusicon on the login screen.