Plymouth Multi-head support
September 29, 2009
So it’s been a while since I’ve blogged.
This is just a short blog post to say that I landed multi-head support on plymouth master yesterday. More details here:
http://lists.freedesktop.org/archives/plymouth/2009-September/000188.html
What this means is the boot splash redraws itself once per monitor, in a way that looks good for the native resolution each monitor. Previously, we’d draw right on the fb console, which is cloned across all monitors. That made the splash have large black margins on some monitors, or look stretched.
One implication of this change is we now use libdrm directly when possible instead of going through the /dev/fb interface.
We still don’t do any accelerated rendering. We don’t really need it, since plymouth splashes are normally designed to be very simple (Think “cell phone splash” not “3D video grame”).
detached directories
June 18, 2007
So one thing I wanted for my Graphical Boot stuff was a standalone environment for it to work in. I wanted it to have its own /proc, device nodes, etc, because it gets run so early in the boot process that those things aren’t set up yet globally. If I make my program set them up globally, then other parts of the boot process get confused that things are set up already. What I really want is my own private directory that only my process can see and that goes away when my process exits.
This is something you can do with individual files pretty easily. Something like:
int fd;
char file[] ="/tmp/XXXXXX";
fd = mkstemp (file);
unlink (file);
It turns out you can do something similar with directories, too, although there are some caveats. If your program
- creates a temp directory
- mounts a ram filesystem in the directory
- opens the directory and stores the file descriptor somewhere
- lazily unmounts the ram filesystem
- remove the temp directory
Then the directory will no longer be visible from the filesystem, but will exist as long as the stored file descriptor is opened. The program can fchdir() to the directory using the saved file descriptor and work with it. Now some of the caveats are:
- the program needs to be root to mount the filesystem
- MNT_DETACH (the mount flag used to lazily unmount a filesystem) is unsupported api
- you can’t mount other filesystems in your detached directory
Overall, it’s kind of a neat concept, but those caveats make it fairly impractical to use.
Graphical Boot up!
June 9, 2007
So gnome blogs now has a nice wordpress setup thanks to Jeff Waugh, so I thought I’d take the opportunity to maybe start blogging. I don’t know if I’ll keep it going–all my past attempts have failed pretty miserably.
Anyway, at work right now I’m working on trying to lay some of the ground work toward getting a prettier boot sequence for Fedora. We have a wiki page that covers an overview-y superset of what I’m currently working on.
Specifically, my goals right now are to
- get a graphical splash screen up quickly
- have it do something interesting for the entire boot sequence
- not show any text during bootup
- have all the text we show during bootup now, available in a file after bootup
- have a way for users to turn off graphical boot up easily
A lot of this work is motivated by previous work by Kristian Høgsberg
What we currently have in Fedora is RHGB. It’s a small program that gets started as soon as /usr is available during bootup. The program starts an X server, throws up a progress bar that updates as boot progresses and has a detailed view that shows a terminal window with all the mesages in the middle of the screen.
RHGB has a number of disadvantages:
- boot up stalls (for as much as 10 seconds or more!) until the X server is started
- it’s X server is different than the X server GDM uses
- this causes flicker from all the VT switching and mode changes when going from text mode to X to rhgb to text mode to X to gdm
- this triggers X driver bugs that have issues starting multiple X servers simultaneously or in quick succession
- the details mode is ugly
- boot messages aren’t logged
What I’m working on now has a subtle (although still somewhat unpolished) animation that fades the fedora logo in and out against a dark blue background. Rather than having a traditional progress bar or spinner, I randomly add a new twinkling star somewhere on the screen whenever there is boot progress. It’s just a off the wall idea I’m using for test purposes right now. The framework for displaying the animation is intended to be somewhat flexible, so that the animation is simple to write and can be changed out easily (somewhat analogous to a screensaver, I guess).
Boot progress is reported using the same interface that RHGB takes advantage of now. The init scripts manually call rhgb-client –update whenever something interesting happens and rhgb-client –quit when its time for the splash screen to go away. It may make sense to do something different on this front in the future, not sure.
Boot messages are trapped by creating a pseudo-terminal early on and redirecting the console to the pseudo-terminal. This happens before anything else is run (even /bin/init!), in the very top of the initial ramdisk. Changing the initrd over to use the interface is as easy as changing the shebang line at the top of /init from
#!/bin/nash
to
#!/bin/plymouth /bin/nash
and installing the binary and support libraries in the ram disk image. /bin/plymouth sets up the psuedoterminal and passes off to /bin/nash transparently.
The messages sent to the pseudo-terminal are buffered until the filesystem is fully mounted and then the buffer is dumped to /var/log/bootmessages.log
For development purposes I’m using the standard vesa framebuffer implementation that’s sitting in the kernel, but we probably won’t ever ship anything that uses that. It’s just not a reliable enough solution and it doesn’t really play well with X (which is important if we want to get nice transitions between booting to sitting at the login screen). Right now there are efforts by Jesse Barnes and a few other people underway to get a a reliable drm modesetting interface set up for intel video hardware. It’s likely that we’ll punt shipping anything until that stuff lands upstream.
Anyway, you can follow my progress at a git repository I set up here:
http://people.freedesktop.org/~halfline/plymouth/