Send plymouth mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."
Today's Topics:
1. Using plymouth in Gentoo (Daniel Gultsch)
2. Re: Using plymouth in Gentoo (Ray Strode)
3. Re: olpc boot splash (Peter Robinson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Apr 2009 22:24:11 +0200
From: Daniel Gultsch <[email protected]>
Subject: Using plymouth in Gentoo
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Hi guys,
I recently found a video showing Fedora booting with plymouth and I
liked it. So I wanted to use plymouth with my favorite distri (gentoo).
I know I'm enduser and the info text on freedesktop.org says plymouth
is not meant to be installed by end users but I want to give it a try.
I have KMS running and am using my own initramfs anyway (encrypted root
disk) so how hard can it be? Can anybody please give me some straight
forward hints on how to use plymouth? (The INSTALL file is empty and
the README file is boring)
What I would guess is: Compile plymouth. put plymouthd (and it themes)
in initramfs, do the initial root partition decryption (ok this is
just for me) start plymouthd. mount rootfs. and then?
Well I could install fedora and analyse the way they do it. unpack the
initramfs and stuff, but would be easier if somebody could just tell
me. I'm even willing to give something back and convert your hints
into an easy step by step howto.
thanks
Daniel
------------------------------
Message: 2
Date: Fri, 1 May 2009 08:12:26 -0400
From: Ray Strode <[email protected]>
Subject: Re: Using plymouth in Gentoo
To: Daniel Gultsch <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> I recently found a video showing Fedora booting with plymouth and I
> liked it. So I wanted to use plymouth with my favorite distri (gentoo).
> I know I'm enduser and the info text on freedesktop.org says plymouth
> is not meant to be installed by end users but I want to give it a try.
> I have KMS running and am using my own initramfs anyway (encrypted root
> disk) so how hard can it be? Can anybody please give me some straight
> forward hints on how to use plymouth? (The INSTALL file is empty and
> the README file is boring)
So the basic idea is you need to:
1) build plymouth into the system. On fedora we use these conffigure flags:
.%configure --enable-tracing --disable-tests --without-boot-entry \
--without-default-plugin \
--with-logo=%{_datadir}/pixmaps/system-logo-white.png \
--with-background-start-color-stop=0x0073B3 \
--with-background-end-color-stop=0x00457E \
--with-background-color=0x3391cd \
--enable-gdm-transition \
--with-system-root-install \
--with-rhgb-compat-link
%configure is a macro that expands to:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
(and some other stuff)
%{_datadir} is just /usr/share
You probably won't need --with-rhgb-compat-link since that's only
there for compatibility with Fedora's old infrastructure.
--with-system-root-install makes plymouthd and plymouth install
themselves into / instead of /usr. This is important so that the
plymouth client can work in cases where the root fs is mounted, but
/usr isn't yet.
Somehow you need to hook into your distros mkinitrd mechanism. I
mean you need to copy the plymouth binaries, plugins, and data files
into the initrd everytime you rebuild your initrd. See
plymouth-populate-initrd for how we do it on fedora (mkinitrd calls
plymouth-populate-initrd). I would like to upstream hooks for other
distros mkinitrd systems, so the out of the box experience is easier.
Inside the initrd, you need to start plymouthd early. The earlier the
better, but not before /sys, /proc/, and /dev/pts are mounted, and
not before /dev/tty[01] and /dev/fb0 are created.
At some point during the initrd you need to load the kms driver.
After it's loaded the graphics mode should get set up and /dev/fb0
will be functional. That's when you call plymouth --show-splash to
show the splash screen.
To decrypt your root, run
lymouth ask-for-password --command="/sbin/cryptsetup luksOpen -T ..."
where the --command is whatever makes sense for you.
Right after you mount the root file system (but before you switch to it), run
plymouth --newroot=/wherevertherootismounted
This tells plymouth it can load some files off the real filesystem
(like fonts, and stuff we don't want to stick in the initrd).
while boot you need to run plymouth --update=some-milestone-id
periodically to update the progress bar.
When / is mounted read-write you need to run
plymouth --sysinit
Finally, when plymouth is done, you need to run plymouth --quit
I have to run to catch a bus but i think that's the basics.
> I'm even willing to give something back and convert your hints
> into an easy step by step howto.
That'd be great!
--Ray
------------------------------
Message: 3
Date: Fri, 1 May 2009 16:06:44 +0100
From: Peter Robinson <[email protected]>
Subject: Re: olpc boot splash
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
>>>> Do you know what the policy is for getting plymouth plugins upstream?
>>>> or do we keep it as a separate thing?
>>> I've kind of flipped-flopped over whether all plugins should go
>>> upstream in the past. ?In many ways it makes a lot of sense for
>>> plugins to go upstream, since the plugin API isn't stable, the project
>>> isn't that big, etc. ?On the other hand, we don't want plymouth
>>> tarball releases to get too huge either.
>>>
>>> We do want to make sure that the plugins are generally useful though.
>>> I guess what I'm saying is, I think we want plugins upstream that
>>> aren't very distro specific.
>>
>> If that's the case you need to have published docs how to build
>> packages that can link against the core plymouth to make it easy to
>> build against.
> Note I'm not saying that the OLPC plugin should be built out of
> tree--quite the opposite. ?The point of the mail was to discuss ways
> to intergrate it.
Ah, OK, sorry I got the wrong end of the stick then.
>>> The way we get around the distro-specific problem currently is we have
>>> configure options ?--with-logo , --with-background-color etc. ?By
>>> default these values are a made up "bizcom" logo and a gray color, but
>>> Fedora, for instance, sets the logo to the fedora logo and the
>>> background to blue. ?Plugins source these values to figure out what to
>>> show. ?This way the "fade-in" plugin shows bizcom fading in and out by
>>> default, but on Fedora it shows the fedora logo fading in and out
>>> (likewise for the other plugins).
>>
>> How would that work for things like Fedora remixes where there would
>> well be two logos like in the olpc demo (although the remix logo might
>> not be used as it might not be Fedora).
>
> So what I was saying is we already have --with-logo. ?This gets turned into
>
> PLYMOUTH_LOGO_FILE
>
> which can be referenced in the code. ?We can add --with-small-logo, or
> --with-emblem or whatever, too.
OK. So where the fedora remix logo currently is we replace with
--with-logo so that debian/gentoo/ubuntu or whoever wishes to use it
can substitute appropriate logo?
> This way, you have one distro defined logo for the center of the
> screen, and one distro defined logo for the corner.
>
>>> The configure options solution isn't great, though. ?What if your
>>> background is a gradient instead of a solid color? We solved that
>>> problem by adding --with-background-color-start/end-color-stop
>>> options. ?Clearly, though adding more and more configure options
>>> doesn't scale.
>>
>> Well that wouldn't work really great with the XO as the OpenFirmware
>> goes through to to the bootanim so right from power on through to GUI
>> is the one colour, a bit like the Macs. I would have thought a single
>> colour would be the simplest of all options.
> There's no problem with using a solid color background. ?Different
> plugins do different things, for plugins that do a solid background
> there's
>
> --with-background-color
>
> which gets turned into
>
> PLYMOUTH_BACKGROUND_COLOR
>
> out of the box it's gray, on fedora it's blue, in ubuntu it's orange
> (or whatever). ?The point is to provide a way for the splash to adapt
> itself to the distro. ?Of course, you can ignore
> PLYMOUTH_BACKGROUND_COLOR and just use black, white, or whatever, if
> that's what the splash calls for.
Cool. So we have a default colour if a specific colour isn't defined
by the distro in compile or env vars?
>>> The OLPC plugin seems to have the same sort of problem. ?It has an XO
>>> logo and a fedora logo in it. ?Also it has an arrow based on the XO
>>> logo. ?We can't really upstream those things, because they're not
>>> useful outside of olpc/fedora . ?So some things we could do:
>>
>> I disagree as there's already debXO and most of the OLPC stuff in
>> ubuntu as well so it could easily be used by 3 different distros, and
>> the OLPC Server project which could/would also use it wants to
>> eventually be based off CentOS rather than Fedora.
> My point here is, the plugin has an image in it that shows a fedora
> logo. ?If we upstream that, then when it's running centos it will show
> a fedora logo... ?We need to make it work in such a way that we aren't
> shipping distro specific (and trademarked) logos in the upstream
> tarball.
>
> Basically, from an upstream point of view, we want to be as friendly
> as we can to distros/integrators as possible.
So we have it so there's a generic placeholder where the Fedora remix
logo is (or maybe nothing if there's not a --with-logo defined?), and
allow the option of background colours, and fallback to the default if
there's none defined?
Peter
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 8, Issue 1
**************************************
