Jaunty Plymouth PPA Plugin Development Tutorial (so far)
halfline at gmail.com
Mon Mar 16 07:00:24 PDT 2009
On Sat, Mar 14, 2009 at 4:19 AM, Jonathan Greig <redteam316 at gmail.com> wrote:
> I know you still need some documentation. I posted this on the Ubuntu forums
> in the Plymouth PPA Thread thats been started (
> http://ubuntuforums.org/showthread.php?p=6892088#post6892088 ) to help
> others get involved with the project. Towards the bottom, I figured out how
> to get a single plugin without neccessarily relying on the rest of the full
> source, so a one-off makefile shouldn't be too hard now that I got that
Great. I've always wanted out of tree plugins to work and I did some
of the ground work so it could happen, but I never tried it.
> Most of the info here I collected from the mailing list and my own
> experimentation. Maybe some of this could go into a readme.ubuntu file?
Ideally the distro independent parts would go in a distro independent file. The
ubuntu specific bits could go in a readme.ubuntu or an ubuntu section, though.
> I'm also planning on making PHENIX (Plymouth Hyper-Extension for *NIX), a
> plugin creator/switcher/tester. The script below will eventually be part of
> it. The name deriving from mythology as Plymouth is rising in place of RHGB
> and Usplash. Extension being somewhat synonymous with plug-in.
Might be useful to put this tool in-tree.
> Also I do have some more questions:
> 1) I thought I read somewhere that plugins could be combined. By this, I'm
> assuming that they need to be constructed as separate .cpp/.h files so the
> creator can pick and choose what to include? Or is there something else in
> mind later down the road for Plymouth?
Plymouth is currently C based, not C++ based. There are two types of
plugins "splash" plugins and "control" plugins.
There can only be one splash plugin at a time. It's what draws the
splash screen, asks for a password, etc.
Control plugins are a little weird. Since plymouth runs in the initrd
there is some pressure to make sure we don't depend on a lot
librariies (because every library has to be copied to the initrd)
But in some cases we need access to libraries while plymouth is
running *after* the root filesystem is mounted. A great example of
this is to render text. In order to get proper rendering for the
locale the user is running in, we need to use pango, cairo, freetype,
unicode fonts, translations, etc. We probably don't want to put all
of that in the initrd, but once the root filesystem is mounted, those
resources are in theory available to us. That's the label control
plugins job. It links against pango and cairo etc, and we load it
after the root fs is mounted. After it's loaded we can tell the user
messages like "/home is password protected" in their native language.
In theory you could have multiple control plugins loaded at the same
time, but right now there's only the label one.
There's no generic "plugin manager" type api that lets plugins hook in
in really generic ways. The plugins are more an implementation detail
than an extension framework.
In the case of the label control plugin it's loaded implicilty when a
splash plugin tries to show text (calls
> 2) I thought I read somewhere that OpenGL could be integrated into plymouth.
> Are there any examples or did I just overlook something. If OpenGL could be
> used, technically, couldn't any other lib such as SDL be used also? What
> limitations are there on other libs?
There are no examples using OpenGL. You could probably do it with an
EGL implementation like eagle but I haven't tried.
> 3) I'm still learning the plymouth API bit by bit. Is there an easy way to
> poll for keyboard strokes without invoking a prompt? I know the text plugin
> has something like this but the function is empty? Think Galaxan Plymouth (I
> hope this doesn't sound too odd lol but this would be more entertaining at
I/O goes through "window" objects. There's normally only ever one
window, the main screen. But there could be additional windows if
there are serial consoles hooked up.
If you call ply_window_add_keyboard_input_handler(), you can register
a callback that gets called whenever the user types something.
I don't think a Galaxan Plymouth type boot up makes sense though.
Ideally we want boot up to be fast, like less than 10 seconds fast.
Distro's (and other interested parties like Intel) are definitely
trying to make that happen.
Really you should think of Plymouth more like "cell phone splash you
don't really notice when you turn your phone on" than "interactive
gaming platform". If plymouth is taking resources then it's going to
slow down boot after all... And people aren't booting for the sake of
booting, they're booting to get to a point where they can use the
computer for whatever they want to use it for.
More information about the plymouth