Plymouth ⟶ X transition
November 28, 2009
So one of the big polish bits in the boot process is the transition from plymouth to X. In Fedora, we worked to make it as seemless as possible when we first started on the Better Startup stuff a few releases ago.
If you haven’t seen it, when boot up finishes, plymouth settles down the boot splash to a transitionable animation frame, then the mouse pointer shows up, and GDM’s background cross fades in while the login window maps and expands to show frequently logged in users. In the best case, this transition all happens without any flicker, resolution changes, black intermediate screens, or console text showing up.
The way we accomplished this was:
- I gave “plymouth quit” a “–retain-splash” option which told plymouth to keep the boot splash’s contents on screen even after plymouth exits
- krh and ajax added a -nr option to the X server to make X not clear the screen to black (or a weave) at start up
- krh, airlied, and darktama (Ben Skeggs) added the driver backend support for -nr to intel, ati, and nouveau drivers respectiviely. Also, Bill Nottingham made -nr work with the fbdev X driver.
- ajax made the ugly big “X” mouse cursor not show up by default
- I made gdm stuff the screen contents to a pixmap referenced by the pseudo-standard _XROOTPMAP_ID root window property
- I also made gnome-settings-daemon cross fade from the _XROOTPMAP_ID pixmap when it loads its background. This step meant we also get a nice transition from gdm to the user’s session, because it also causes a crossfade to happen from gdm’s background to the user’s background during login.
Another big piece to the puzzle was kernel modesetting. This is what makes sure the right mode is set at boot up from the start. Jesse Barnes and krh did most of the work for that in the Intel driver (based on top of the memory manager work anholt, keithp, and other Intel crew did), while airlied did it for the ati driver, and darktama did it for nouveau.
This all works pretty well these days, but one big wrinkle in the whole process is the hand off from plymouth to gdm. Plymouth exits, leaving the system in KD_GRAPHICS mode and hopes that X starts and picks up the peices. This is not a very robust design, because if X doesn’t start, the system will be stuck in KD_GRAPHICS mode and the user won’t be able to switch VTs or really do anything at all, but reboot.
Furthermore, when plymouth exits, the kernel sets the scan out buffer to the frame buffer of the console. This is because the previous scan out buffer was owned by plymouth and goes away when plymouth exits. That means in order to keep things seemless we need to copy the last frame of the animation from plymouth’s framebuffer to the console frame buffer. This extra copy is unfortunate, because it means the kernel console has to be configured the same way as plymouth, but in multihead set ups it’s not. The kernel console “clones” the ttys across all heads, forcing every head to be the same resolution. But plymouth (and X) want every head to run in native resolution. This means in multihead setups we can’t do the copy because the pixel layouts aren’t the same, so we end up filling with black instead.
I’ve wanted to improve this situation for a while, but haven’t really been able to prioritize it above other various bits of work that need to be done. Since I’m on Thanksgiving break I can, in good conscience, ignore my priority list and just work on what I want, so I decided to work on this problem a bit :-)
I just merged the “no-fbcon” branch to plymouth master. It adds a new way to “deactivate” plymouth such that it’s still on screen and idly running, but X can start and take over anyway. This combined with some gdm changes to tell plymouth to go away in the appropriate way after X is started or fails to start means we solve the robustness issues and avoid the extra fbcon copy.
It actually only took a few hours to do. I probably should have made time for it before break.
November 28, 2009 at 7:05 pm
I think that the best way to create innovation is to replace all X.org
I don’t know why people try to lose their time hacking X to include some features, than coding things from the begining.
There would be some time lost in the begining, but after, we will shortcut development time for developers and testers.
November 28, 2009 at 8:39 pm
“because if X doesn’t start”
Nobody I know is going to do anything but restart at that point anyways, so I don’t get why this is a concern..
November 29, 2009 at 12:25 am
that sounds very good, it’s tempting me to leave ubuntu for a while an try fedora.. keep the good work!
November 29, 2009 at 3:52 am
Nelson, if you want to give Fedora a try, I’d recommend giving Fedora 12 a try as a live image on a usb stick. It’s a good way to “try before you buy”.
Ethana2, I agree if X doesn’t start it’s already fail. That’s why the old way was “good enough” for the last couple of Fedora releases. Still, doing it this new way will be more robust and solve the other mentioned issues (and some other issues I didn’t mention if the ati driver switches to a lower colordepth fb console by default)
boulabiar, I think you may be underestimating the time investment in replacing X wholesale. X is being replaced at this momement, but piecemeal. The underlying technologies are getting rewritten and modernized. Those same pieces are being leveraged by a project by krh called Wayland which some day may supercede X, but will hopefully supercede the broken VT subsystem first.
I did some work on wayland earlier this year here:
http://cgit.freedesktop.org/~halfline/wayland/log/?h=dbus-attempt
but haven’t worked on it recently.
November 29, 2009 at 5:49 am
I’d just like to say that you, and all the others you mentioned are terrific people. Booting up is so cool now!
November 29, 2009 at 11:45 am
Any news about KDM? Or, to put it in another way, any hope for KDM integration in the future?
Please don’t leave KDE users totally in the dark! :)
They’d like to have Plymouth integration too!
http://www.phoronix.com/news2forums.php?view=Nzc0Ng
http://lists.fedoraproject.org/pipermail/fedora-kde/2009-September/003923.html
November 30, 2009 at 1:23 am
Hey Diego,
I’m not likely to do the work for KDM, but others may at some point. I’m happy to answer any questions anyone has who wants to do that work.
I’m one of the upstream maintainers for GDM and a long time GNOME developer, so it’s a codebase and platform I’m enthusiastic about and most comfortable working with.
November 30, 2009 at 11:23 am
Aha, I see. Thanks for the reply!
I hope KDE-SIG or Mandriva will take care of this.
December 1, 2009 at 10:27 am
I heard that Ubuntu will be ditching their brand new Xsplash system in favour of Plymouth, so if this actually ends off being true then thanks for making Plymouth more robust :-)
I think it’s pretty cool that you can just ask the Xorg developers to add a particular feature for you. Definitely one of the strengths of the open-source community.
December 1, 2009 at 3:01 pm
Hey Chris,
Yea, Keybuk and tseliot (who both work on Ubuntu) are in #plymouth most days getting things ready for their next release.
Note the Xorg developers didn’t just implement features because I asked them, too. Most of them are Fedora developers as well, and so the “Better Startup” effort was a coordinated from the start.
December 13, 2009 at 9:56 am
Good news, Rex Dieter prepared a patch for KDM. =)
December 13, 2009 at 9:57 am
Forgot the link:
https://bugs.kde.org/show_bug.cgi?id=206089#c2