A Closer Look At Red Hat's Plymouth

[deanjo]

It would also be nice to see Plymouth (or some adaptation of it) supported by other Linux distributions.

Supported? It's open source, just install it in Ubuntu if you want it in Ubuntu. So what if it doesn't come with it by default. I guess that's one reason for rolling your own distro, but yeah I hope most desktop Linuxes will come with this software in the future because most users will want it I reckon.

Linux needed a boot process sleek enough to match Mac's. I hope the next step will be to implement this in the Linux BIOS as well, so that it will be possible to go from power on all the way to your desktop with no flickering or changing of resolutions whatsoever.

Well I'm for one that is not thinking this is the greatest thing since sliced bread. I prefer to watch the verbose boot up processes watching for unexpected issues that these splash screens cover up. Hell I disable the startup splash on OS X too.

[fat_chris]

Question for Airlied:
I have been try to get KMS working on another distro (gentoo) but have so far been unsuccessful.
I've got the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git (drm-rawhide branch) built it with modesetting on by default all built fine, libdrm from git://git.freedesktop.org/git/mesa/drm.git (modesetting-gem branch) and xf86-video-ati from git://people.freedesktop.org/~airlied/xf86-video-ati (branch radeon-gem-cs). When I boot without nomodeset it will get to openrc and then load the modules where I get a blank screen and a no signal message on the screen. In the logs it pretty much just says that it can't find anything connected to the graphics card (r580 x1900 xt) and it says the drivers loaded fine. I also tried building drm and radeon into the kernel but the same happens just much earlier in the boot process.
Is there anything else I need to do/enable/install?
Any help is appreciated

[elanthis]

Well I'm for one that is not thinking this is the greatest thing since sliced bread. I prefer to watch the verbose boot up processes watching for unexpected issues that these splash screens cover up. Hell I disable the startup splash on OS X too.

Congratulations -- you're a statistical anomaly.

The neat thing about Plymouth is that you should still get those messages. With RHGB I recall that if an error occurred, it immediately switched to the details mode that showed the console output. I believe with Plymouth it will show you all errors once GDM starts inside of a log window.

[Yfrwlf]

Yfrwlf, I think you failed to read the whole article.

It's pretty clear that you can NOT just install Plymouth into a distro and actually have it work. It needs tight integration with the distro to actually work. It needs to properly inserted into the initrd (which will require an entirely different set of commands and scripts than Fedora uses) and the init system needs updates to communicate with Plymouth properly. Plus I'd imagine you'd need to change the GDM startup to use the new features to not reset the video mode and get smooth fade-in.

If Ubuntu/Debian/SUSE/etc. want Plymouth, the distro engineers are going to have to integrate it, which will take a fair amount of effort.

It is not at all something a regular user -- or even a moderately advanced user -- would be expected to know how to do properly.

Then it's a failure of a project so far for end users. Using package dependencies, you CAN install the required software in any Linux distro, it's completely possible, they just haven't done it yet so I hope they will. Shame on Red Hat for making software which is difficult for anyone to install and use but if it's "still in alpha" then fine. Regardless, that is not the way you gain community support when the Linux community can't get easy access to your software, so if they want more developers and more bug reporters and such to come in and help with this Plymoth project, they need to get things together and organized so you don't have to be a programmer to use the damn code.

Again, if it's still just "alpha-grade" software, I can give them a break, but they're only hurting themselves and the development process by making their software difficult to use and experiment with.

Previews of upcoming software is nice and all, but it's much nicer if us Linux users can actually have access to it so we can try it for ourselves. Duh. I'm not saying anything that isn't completely obvious. I hope Plymoth will be available for Linux users to try in the future. Fxxx exclusive distro lock-in.

[Yfrwlf]

Well I'm for one that is not thinking this is the greatest thing since sliced bread. I prefer to watch the verbose boot up processes watching for unexpected issues that these splash screens cover up. Hell I disable the startup splash on OS X too.

Sure, and that should always be available for users who want it, I love the ability to hit ESC and see it all, though if there ARE errors the graphical mode should show you those any way, like elanthis said.

[elanthis]

Then it's a failure of a project so far for end users. Using package dependencies, you CAN install the required software in any Linux distro, it's completely possible, they just haven't done it yet so I hope they will.

Stop. Seriously.

I am one of the HUGEST proponents of the "Linux needs to make software installation not suck donkey balls" movement that thinks the appliance-nature of current distros software models is essentially useless for real users. I willing to be that I've written more artiles (a.k.a. rants) on the topic than anyone else.

But that has nothing to do with Plymouth. Plymouth is not an application you install. It is a core part of the distribution that must be integrated at a software level. It requires code modifications to work. It requires patched applications. It requires a ton of changes that must be done at the source level, and those changes are to components that are customized for each distribution.

It IS NOT AN APPLICATION for you to install. You might as well claim that Windows' SVCHOST is broken because it can't be installed/uninstalled just like any other application.

If you want Plymouth that badly, go ahead and integrate it with your distro, and send the patches upstream. I'm sure they'll love it. It's just in any way even remotely technically feasible to make a package that can magically install it, modify your initrd, modify your initscripts, patch your GDM and xorg packages, patch your kernel, and modify your grub and early bootup config files. This is just something that sits at the lowest levels of the OS, below the components that are expected to be user manageable.

[Yfrwlf]

Stop. Seriously.

I am one of the HUGEST proponents of the "Linux needs to make software installation not suck donkey balls" movement that thinks the appliance-nature of current distros software models is essentially useless for real users. I willing to be that I've written more artiles (a.k.a. rants) on the topic than anyone else.

But that has nothing to do with Plymouth. Plymouth is not an application you install. It is a core part of the distribution that must be integrated at a software level. It requires code modifications to work. It requires patched applications. It requires a ton of changes that must be done at the source level, and those changes are to components that are customized for each distribution.

It IS NOT AN APPLICATION for you to install. You might as well claim that Windows' SVCHOST is broken because it can't be installed/uninstalled just like any other application.

If you want Plymouth that badly, go ahead and integrate it with your distro, and send the patches upstream. I'm sure they'll love it. It's just in any way even remotely technically feasible to make a package that can magically install it, modify your initrd, modify your initscripts, patch your GDM and xorg packages, patch your kernel, and modify your grub and early bootup config files. This is just something that sits at the lowest levels of the OS, below the components that are expected to be user manageable.

Other software needs to be updated/changed in order for them to work with Plymouth. I.e. interoperability/integration. Nothing you're saying can't be done by a package though although it may be difficult, sure. As far as I see it, there are two options. Plymouth can communicate clearly with these other programs so that it can tell them what it needs done when it is enabled. This would be the best solution as you need to get away from *hard coded* differences, and instead use APIs that allow flexibility and modularity. So, Plymouth needs a way to communicate and/or configure these other pieces of software while remaining neutral so that it can be more easily replaceable by other software which is similar to Plymouth. The other option would be to update all the other software and have special "Plymouth editions" of them.

I'm not telling you how things are. For all I know, all this integration isn't smooth and modular and the communication isn't nailed down yet, so heavy modification to get Plymouth running, like you said, may very well be what is required right now, OK I accept that.

I'm telling you how things should be, and I think you'd agree. So, we're done there then. I hope these programs all mature more and/or become more standardized or gain standardized interfaces or whatever it takes so that the whole system is easier to tweak and will allow for an easier time of installing things like Plymouth in the future.

Those are problems that I would be working on first if I were working on the Plymouth project, are ways for it to play nicely with other software so that users could easily install it. I wouldn't even begin programming until I could work out a nice modular system for installation and communication/integration with everything else. Then, I would use those APIs or whatever me and whoever else came up with when I made my program, or I'd make my program compatible with those APIs after-the-fact.

[elanthis]

Other software needs to be updated/changed in order for them to work with Plymouth. I.e. interoperability/integration. Nothing you're saying can't be done by a package though although it may be difficult, sure. As far as I see it, there are two options. Plymouth can communicate clearly with these other programs so that it can tell them what it needs done when it is enabled.

No, it is not able to be done with a package. Seriously. Because any package would have to replace existing components with updated components, and since you'd want to keep other distribution customizations of those components, you'd essentially need a package for each distribution. Which takes you right back to the distribution developers needing to integrate Plymouth versus just being installable by users.

Plymouth _does_ use an API to communicate with components. But the simple fact is that those components have to be modified to use that API, because there was no such API before.

And you still have to deal with components needing patches. In order for Plymouth to work the way it does, X needs to not change mode on startup, or blank the pixmap, or so on. Once those patches are upstream and all distributions are already shipping versions of those packages with those patches, then sure, Plymouth would be easier to just install as a package, but you're still going to have to deal with differences like the initrds, or even the package management system itself.

Installation of software needs to be easier, yes. But not for things like Plymouth. It's not something that should _need_ installing, as it's something that should just be built into your distribution. Things like that don't need easy installation, and don't make sense to even advertise to users as components they can install or uninstall. It's a little irritating at first because your distribution doesn't ship Plymouth, perhaps, but that's unavoidable. Distributions like Fedora exist almost solely for the purpose of being test beds for software like this, while distributions like Debian or SUSE try to be conservative. If you want to use bleeding edge low-level OS components, use an OS that was intended for that purpose, not one that's meant to be stable and reliable.

</tangent>

[fat_chris]

Well I finally got KMS working on gentoo. I had to get a src rpm kernel from fedora then compile it as the sources in airlied's git repo mustn't have been sufficient.

If anyone else wants to try KMS out on gentoo:
- Get the x11 overlay with layman (layman -a x11)
- Take the -9999 (git) ebuilds for libdrm, mesa and xf86-video-ati
- Delete the x11 overlay if you want (layman -d x11)
- Modify the ebuilds by putting the line EGIT_BRANCH="<branch>" BEFORE the inherit line.
- Change EGIT_REPO_URI="<whatever>" to the URIs in my above post and match them with the branch
- Put these ebuilds in your overlay and merge!

BTW - I can't compile the r300-buffmgr branch of mesa so it might be worth trying r300-bufmgr-fedora

- To get the kernel got to koji.fedoraproject.org search for kernel, get the latest src.rpm
- Now, you can either use rpm2targz and apply the patches on by one...
Or you can `emerge rpm` and then follow the guide at > http://fedoraproject.org/wiki/Docs/CustomKernel < use only the parts that are applicable.

Hope this helps some other people.

Edit: It's still not working as it should. I'd say it only works about 1 out of 3 boots but I don't know why as there is nothing different in the failed logs than the successful logs. Any ideas?
Edit2: Working fine now, I have 3D to a degree... I can run glxgears but not kwin4 compositing but I suspect this is because I can't compile the mesa branch.
Edit3: Managed to compile the mesa branch. It turns out there was a problem with my dri2proto. So, now I have kwin compositing and KMS!!

[curaga]

Sooo.. This really looks quite cool. However, this was already possible with bootsplash, including the animations. Can someone fill me in on what is special?

It uses KMS to get less flicker, and shows the pic later than bootsplash, and probably uses some amounts of ram and so does not run on machines older than variable Y. But what else?