Monday, January 22, 2007

Plymouth

Leading up to FUDCon, I figured I should expand a bit on the "executive summary" from the previous post. Plymouth is the code name for the next generation RHGB (Red Hat Graphical Boot) effort, and as I hinted in the previous post, the key idea is to put the X server in the initramfs. I'll try to summarize the discussions that have led to this approach below.

A number of distros have an fbdev based graphical boot solution, and while these generally work reasonably well, the problems outweigh the benefits, even in the short term. First of all, we don't want to rely on and maintain two different code paths for mode setting. Mode setting is difficult, yet boring, so it's not like there's a lot of developer manpower in this area. All in all it makes sense to choose one code path and make sure that works.

Second, the fbdev drivers is a point of contention - on one hand they seem to work very well for embedded uses where you have a small PDA type of device with just one screen, on the other hand, the fbdev abstraction just doesn't scale to the requirements of a modern, multihead, monitor-hotplugged desktop. A more flexible kernel based mode setting might just happen and that is great, regardless of whose idea it was to begin with. But that is the longer term solution, and until that work materializes we need something better than the current RHGB, and ideally something that pulls in the right direction.

Since X has to work for desktop usage it only makes sense to bet the farm on the X modesetting code. This is what RHGB does, however, RHGB loses a lot of its punch when it's only started halfway through the boot sequence. Also, all the flickering as we go from grubs 640x480 graphical menu back to text mode, into the RHGB X server and then into the real X server doesn't exactly make for a nice experience. Which leads us to the idea of starting X as early as at all possible - in the initramfs.

Short of doing modesetting in the kernel, this is the earliest we can initialize the video card. Once the X server is running, the idea is to use this server throughout graphical boot, login screen and user session. This allows for controlled transitions between these phases as opposed to crazy flickering while your monitor goes in and out of sync a few times. Of course, a fair bit of integration work is required across the initramfs tool, init scripts, GDM and gnome-session (or KDM and ksession) for this to work. Another quirk is that starting the X server from the initramfs prevents us from unmounting, which keeps the 5M of unswappable memory around. We've been discussing shutting down the X server while keeping the mode set and then starting the real X server from the real root file system in a way such that it just "inherits" the mode already set.

Using the mayflower initramfs creator from Davids livecd-tools with this patch, I was able to create an initramfs that included the X server, the DDX driver and the necessary modules in just under 5M. Booting with this ram disk lets me get from grub to X in under 5 seconds on a typical desktop machine. As a proof on concept, that's pretty encouraging, but it's just the first tiny step towards implementing this idea.

8 comments:

eric said...

We've been talking about eventually doing a kernel modesetting API, now that we've figured out how to actually design one with RandR 1.2. And if we keep kernel modesetting orthogonal to the memory manager (I think that's doable) and the DRM (no interactions there), it sounds like a tractable project. So there's significant hope that this won't be necessary in the long term.

However, I've also been thinking about flicker reduction due to the serious regressions in flicker count at X server startup due to my laziness. It seems like, with the RandR 1.2 code we've got, I should be able to bring the flickers down to 1 or 0 depending on what the mode was before the server got a chance (basically, detect what modes are currently set and what outputs are on at server startup, elide no-op mode sets, place a preference somehow on the pre-set mode when appropriate, and avoid setting up load detect pipe settings when the pipe is already on). I don't think this would be much work, and would be awfully nice until we get our kernel modesetting of doom done.

ahe said...

Kristian, this would be wonderful. Please also make it work for proprietary X servers.

MacSlow said...

Hey Kristian, rock&roll for that. Great news to read about!

k0k said...

Great News.

Edoardo said...

To me, console boot messages are fine. Oh yeah, I'm an old fart and on servers, why glitz? ;-)

e

npmccallum said...

Any status update on this?

Also... Wouldn't be easier, and useful outside your project, to add a persistence mode tmpfs? Something like:
1. Allocate shmem
2. Pass a reference to that memory when mounting tmpfs
3. tmpfs uses the shmem for its memory
4. umount tmpfs doesn't clear the memory
5. pivot root
6. mount tmpfs again with the pointer to shmem
7. continue on...
8. umount tmpfs when done
9. free shmem

It would seem that such functionality could be useful in various scenarios and would solve the un-umountable initramfs issue.

npmccallum said...

Nevermind, you can do this all in userspace via clone() (CLONE_NEWNS).

pirast said...

remove the spam please? -.-