Ray Strode

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:

1. I gave “plymouth quit” a “–retain-splash” option which told plymouth to keep the boot splash’s contents on screen even after plymouth exits
2. 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
3. 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.
4. ajax made the ugly big “X” mouse cursor not show up by default
5. I made gdm stuff the screen contents to a pixmap referenced by the pseudo-standard _XROOTPMAP_ID root window property
6. 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.

So Fedora 12 is finally out. Give it a try.

It shaped up to be a pretty good release I think.

So I’m at the Boston Summit this weekend. Mo showed off her portable usability lab. She posted about the lab before here. Jason Clinton posted a summary of the summit session here

The DVR hardware in the setup ouputs four avi files–one for each camera. The first file has the audio encoded in it. Having four files is cumbersome, though. It’s much better to see the camera focused on the users face at the same time as video focused on the users hands, and at the same time as the view that shows the users screen.

That’s where gstreamer comes in. It’s possible to write a pipeline that can take the 4 videos and compose them together into one 4-way split screen.

In Mo’s post she showed an earlier pipeline I came up with, but it was very slow and lacked audio.

I’ve been reading up on gstreamer, searching the internets for example pipelines, etc, and now have a better pipeline. Someone here at the summit asked for me to check it into git, so I did that today in the usability-lab module.

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”).

So, just a quick note to say Fedora 10 is out.

If you haven’t tried Fedora in a while, and you’re curious give the live image a try on a USB stick.

So I came across a really interesting mailing list post by ajax today. He’s totally right and it’s refreshing to see…

So, I am totally surprised to see that Matthew Szulik is stepping down as Red Hat’s CEO.  I wonder what comes next…

So there has been a lot of discussion recently about the key import dialog in PackageKit recently. We were talking about it on the bus on the way to work this morning, in fact. Here’s my thoughts (and some thoughts I didn’t come up with, but came from the bus discussion):

• Showing the fingerprint in the dialog is only useful if the fingerprint is somewhere else the user knows to look
• You obviously can’t put where to look in the key itself, because the key isn’t trusted until the fingerprint is verified
• Since you can’t put it in the  key, discoverability is a hard problem.  We pretty much have to hope that the key is in plain view on the website that offers the package / repo.
• “trust” is a bit of a stretch in any case, because often users will google around for software and install whatever they find. It’s really more “verify the software comes from the website that originally pointed to the package / repo file.”
• Only users who really understand the security implications of the dialog are going to verify that the key fingerprints  match
• Given that most people who see the dialog aren’t going to verify that the key fingerprints match, the dialog isn’t useful for security (it only solves the identification problem for a small subset of users)
•  One way to make the dialog more secure would be to treat the fingerprint like a CD key / activation number that the user has to enter instead of something that gets shown to the user.   If entering the key was a required step for configuring a system to use a repository, then websites that offer repositories would have to include the fingerprint with the repo in plain view for the repo to be useful, and users couldn’t just click past the dialog without reading it.
• Some might argue that users are accustomed to entering these types of numbers already when installing software.  There’s precedent anyway.
• Having to enter long strings of numbers sucks (just as much as having to read long strings of numbers sucks)
• Either way, there’s a very real aesthetic problem with this type of dialog, and it’s not clear there’s an easy way to fix that
• One thing that can help is have the distribution know about a select number of 3rd party repos/keys out of the box, so then the dialog can hide the key fingerprint entirely.
• Figuring out which keys to ship within a distribution is an interesting problem itself, but maybe it should have some parallels to the processes that the distribution uses for adding packages?

So I just wanted to publically say congratulations to my friend, Dave Malcolm (of Conglomerate, Evolution, and Dogtail fame), since he’s going to be marrying a great woman soon.

Congrats Dave!

So I was playing around with PulseAudio which will be the default in Fedora 8 and it’s definitely cool.

I played a movie in totem (actually the Truth Happens video) and the sound went out my speakers. I then plugged in a USB sound card with headphones hooked up into it and ran the pulse audio control capplet-thing. It has a page that says “Active Streams” on it or some such and on that page was a list that had Totem. I right clicked on the Totem item, and a context menu popped up that showed my laptop sound device, and the usb sound device. I picked the usb one and sound immediately and seamlessly changed to the headphones.

That was pretty neat and played around for a few minutes just switching it back and forth between devices, then I found out something really cool. The music was playing through the headphones, then I unplugged the usb sound card, and PulseAudio noticed the device went away and transparently switched the movie sound back to my laptop speakers!

I guess it does the right thing when you have multiple users logged in at once too. The active user always get a sound device and any audio getting played by inactive users goes to /dev/null.

Anyway, bottom line is, Lennart rocks.