Enhancement request to tc-config to support boot splash

[andyj]

I have managed to get plymouth working to show a boot splash for both framebuffer and intel kms graphics. To do this I have two additional initrd's, one for the plymouth executables and kernel modules, and a second for the splash theme. To show the splash I have added a few lines to tc-config between the mounts and the big case statement at the beginning. The problem is that it is somewhat TC version specific; any changes to tc-config would require a rebuild of the plymouth initrd. What would be helpful is if the symlink that is rcS became a real file that just does the initial mounts then passes control to tc-config (which would no longer have the mounts at the beginning). Then, assuming that the need to do the mounts up front wouldn't change, I could (or anyone wanting to port a different splash application) just have a custom rcS with the splash startup commands added to it.  This way tc-config remains unchanged for the version installed and the splash application should then only depend on kernel versions.

Andy

[roberts]

Sounds good. Request granted. Will be implemented.

[andyj]

Awesome. And thanks. As you can tell, I'm relatively new to TC but not new to *nix (a slacker since the mid 90's plus AIX, HPUX, and Solaris). What's the best way to make some of my TC projects available to the community? I could do it from my home web server as a last resort, but I have limited upload bandwidth. I have plymouth for boot splash, a vmware client tools extension, and an Elo touchscreen extension. The last two are closed source, but I could document the "howto build it yourself from the stuff the vendors do make available" if I don't get permission to redistribute their "free as in beer" stuff. Plymouth is open source, so no problems there.

There is one more thing. I've only been successful with the DRI splash when udev is running before I modprobe the kms modules. So, if you can, when you make the split, add a check to see if udev is already running before starting it? If someone knows how to get around this or wants to help with the ati or nouveau versions (as I don't have that hardware), it would be much appreciated.

Again, thanks,

Andy

[curaga]

That (udev check) sounds like going too specific into supporting one solution. I think your issue is that of permissions (or device node not existing), udev running allowing you to access the node.
Since there are so many different bootsplash solutions, I wouldn't want to have such specific support for any one in the base.

Instead of double-starting udev, I would recommend a manual mknod and/or chmod, if that's the reason.


For the non-redistributable binaries, the usual approach is to make a script, and either post it to the Programming and Scripting section, or to make it a getter extension (see getflash).

[andyj]

I'll try the chmod approach in /dev/dri and see if I can get around udev, because I agree that it's ugly and shouldn't be required. It solved the problem I was having at the time and I didn't go back and research it further. The elo.tcz extension has only a dozen files, so a simple get -> unpack -> repack explanation should be easy. VMware is a little more complicated but still possible to document. Plymouth is painful. The author says it is, and he's right. Maybe if he knew how to comment code it would suck less. I was kinda hoping for a way to have people upload splash themes assuming anyone cares enough. If not here then I'll find something.

Andy

[andyj]

This is turning into a real tar pit. The entries for the video card in /sys don't exist until udevadm puts them there. I tried hard coding some of the info in the plymouth source code so as not to have to look into /sys to find the driver, but that didn't work like I wanted. Plymouth tried to load the i915 driver, but nothing happened for a while, and then it fell back to text. I'll have to ponder on this. Any DRI experts here?

Andy

[curaga]

That doesn't sound right, udev has nothing to do with /sys. The modules themselves do that.

It could be firmware, but i915 does not need firmware.

[andyj]

After some more experimenting I've come up with what I believe to be the elegant solution. Since plymouth is an initrd, I added the DRI device nodes and version of ld.so.cache updated with the plymouth libraries to the archive. Now the only thing in tc-config is a modprobe i915 and the commands to start plymouthd and plymouth. An easy addition the the forthcoming rcS. Once the rcS / tc-config split is made and I update my initrd for it, what is the chance of being able to upload the framebuffer and i915 versions along with a TC theme to the contrib directory in the TC repository? All files are less than 1 meg.

Andy

[curaga]

They're already available as module extensions, no? In that case I'd prefer a script to create the initrd from the extension, to not have files in two places.

[andyj]

Because the boot splash has to start at the beginning of the boot process, it can only work as an initrd, and not as a TCZ extension. In this case it's an initrd extension if you will, loaded after core.gz.  Here's a snippet from the currently working tc-config:

...tc-config definitions above... the mounts below would go into a new rcS, and the rcS in the plymouth initrd would add the modprobe and the two plymouth commands before starting tc-config:

# Mount /proc.
[ -f /proc/cmdline ] || /bin/mount /proc

# Remount rootfs rw.
/bin/mount -o remount,rw /

# Mount system devices from /etc/fstab.
/bin/mount -a

modprobe i915

/sbin/plymouthd --mode=boot --attach-to-sesison --pid-file=/var/run/plymouth/plymouthd.pid >/dev/null 2>&1
/bin/plymouth --show-splash >/dev/null 2>&1

... and the rest of tc-config...

for i in `cat /proc/cmdline`; do
        case $i in
                *=*)
... and so on...

and change "initrd=core.gz" to "initrd=core.gz,plymouth-fb.gz splash" in extlinux.conf or pxelinux.cfg/default.

I can see a theme builder extension as a useful thing as the project progresses. It's an iterative process to build the plymouth initrd, so I could document it eventually once I remember all the steps. In this case then the wiki would be the appropriate place. My concern is that the build process is complicated and would require a development box for someone who might just want to try it out. I'd like to be able to offer the ready-to-go one or two file setup in the hope that it might generate some interest.

Andy

[curaga]

Yes, I think you misunderstood me. I mean that since the i915 module already exists in an extension, duplicating it in the hosted initrd wouldn't be good. Instead I meant that there should be a script that inserts the desired modules to the initrd with the theme.

This would allow, among other things, running one's own kernel more easily. Or, if we have to push an update to i915, etc.

I can see a theme builder extension as a useful thing as the project progresses. It's an iterative process to build the plymouth initrd, so I could document it eventually once I remember all the steps. In this case then the wiki would be the appropriate place. My concern is that the build process is complicated and would require a development box for someone who might just want to try it out. I'd like to be able to offer the ready-to-go one or two file setup in the hope that it might generate some interest.

Certainly we'll host the file, but having that document in the wiki will be much more useful in the long run. I'd just prefer it not include any modules, but instead grab them from the extension(s).

[andyj]

Well, yes, given my experience with the i915 graphics some fixes would be welcome. I had envisioned a "code" initrd and a "data" initrd, but a "standalone hardware independent core plymouth code that could last across kernel and library version changes" initrd and a "user hardware and theme" initrd does make more sense from a maintainability standpoint. In this case it would also make sense to build the core plymouth initrd with all the different possible parts, like frame buffer, X11, i915, and ati support. Nouveau is supposed to be supported but I don't have a dev extension for it. Without the kernel modules it should still be under a meg, even if I add in a small default TC theme (like the logo in the middle with some spinning ring). So the next question I have is, how do I put a page into the wiki? Do I need a secret knock, or do I already have the power in my ruby slippers?

Andy

[curaga]

You already have the power, use the forum login details.

[andyj]

Where would the best place for a page for this would be? Setup, Advanced, or ?

Andy

[Rich]

Hi andyj
Either one sounds appropriate, or you could add a Splash Screen topic.