A Closer Look At Red Hat's Plymouth

[airlied]

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

its a bit messy, the libdrm has diverged a bit from the kernel, so using the patches from Fedora probably makes more sense until we line it all up again.

http://cvs.fedora.redhat.com/viewvc/rpms/libdrm/F-10/

the -ati and kernel bits should be fine, its just libdrm that got diverged.

[airlied]

Was just wondering if anyone knew of any way to force modesetting on for r200 series cards, specifically RV250
I believe they don't have it on because it breaks 3d; well the 3d isn't very good anyway...
so I want to try KMS and Plymouth.

radeon.modeset=1 on the kernel command line shuold enable it on r100/r200 at the expense of 3D.

[Yfrwlf]

</tangent>

Alright, fair enough, that's too bad though is all that the framework isn't already in place for it but it's clearly a new framework so that's understandable. If they are helping with that standardization, with that framework/infrastructure for Linux, so that in the future developers can easily snap in their own software, then great and that's all I'm saying is important really. Obviously this software isn't ready for prime time until that infrastructure is in place and ready for it, and I hope that that framework is one that is a good standard so that major infrastructure changes won't be needed much in the future, cept when they upgrade from Plymouth Linux Infrastructure API 1.0 to 2.0. But even then, 1.0 apps should work with 2.0! hehe

[some-guy]

It doesn't require Kernel patches, and is more modular and newer(bootsplash is abandoned)

IMO they should've fixed up splashy instead of many yet-another boot splash app.

----

The reason it CAN'T be done with packages is it requires modifying initrd/initramfs, that is a crucial part of the system and it also requires(most likely) modifying /etc/init.d(or rc.d) scripts

[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?

[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!!

[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>

[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]

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]

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.