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. Re: Jaunty Plymouth PPA Plugin Development Tutorial (so far)
(Ray Strode)
2. Re: Jaunty Plymouth PPA Plugin Development Tutorial (so far)
(Ray Strode)
3. Re: Gradient Framebuffer Fill Bug? (Ray Strode)
4. Re: Spinfinity Plugin Simple 1 Line Fix (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Mar 2009 10:00:24 -0400
From: Ray Strode <[email protected]>
Subject: Re: Jaunty Plymouth PPA Plugin Development Tutorial (so far)
To: Jonathan Greig <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Sat, Mar 14, 2009 at 4:19 AM, Jonathan Greig <[email protected]> wrote:
> Ray/Charlie,
> 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
> working.
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
ply_label_new()/ply_label_set_text()/ply_label_show() )
> 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
> bootup).
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.
--Ray
------------------------------
Message: 2
Date: Mon, 16 Mar 2009 10:19:32 -0400
From: Ray Strode <[email protected]>
Subject: Re: Jaunty Plymouth PPA Plugin Development Tutorial (so far)
To: Jonathan Greig <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi again,
(I hit send to a little too soon before)
> 4) What about sounds?
That's a good question. It might make sense to have sounds, but there
are some complications:
1) No pulseaudio is running
2) No way to change volume
It would definitely be annoying if you're in a library with your
laptop and you turn it on and then during boot up it played loud
noises with no way to stop them.
Anyway, this still needs more thought.
> [b]11)[/b] Now go to the newly created plymouth directory and it will have a
> file called autogen.sh in it. In the terminal type:
> [code]
> ./autogen.sh --prefix=/usr --with-logo=/usr/share/plymouth/bizcom.png
> [/code]
> replacing bizcom.png with something a little nicer if you like.
Probably should have a few more things passed to autogen.sh
In particular, we want localstatedir going to /var which would need a
--localstatedir=/var and plymouth itself
should go to /sbin (daemon) and /bin (client) since /usr might not be
mounted until late in boot up. I added
--with-system-root-install to force that.
> [SIZE="5"][b]How to change the default plugin for bootup[/b][/SIZE]
> [code]
> sudo /usr/sbin/plymouth-set-default-plugin spinfinity
> [/code]
> replace spinfinity with whatever plugin name you want to use. For instance,
> replace spinfinity with solar.
So we need to rebuild the initrd before it will actually show up in
boot up. Right now, plymouth only adds a hook
to the fedora mkinitrd for this to happen (see
plymouth-populate-initrd). I'd really appreciate an ubuntu equivalent
that we could add to the repo.
> [SIZE="5"][b]The proper way to install a plugin from source[/b][/SIZE]
> In the "/yourplymouthgitdirectory/plymouth/src/plugins/splash/plugin-name"
> directory type:
> [code]
> make
> sudo make install
> sudo /usr/sbin/plymouth-set-default-plugin the-name-of-the-plugin
> sudo /usr/libexec/plymouth/plymouth-update-initrd
> [/code]
There's a --rebuild-initrd flag to set-default-plugin
> [SIZE="5"][b]How to make a single plugin[/b][/SIZE]
> On Jaunty, with the PPA packages and git source installed, you can copy one
> of the plugin directories to somewhere else on your drive and work on it
> from there.
> [code]
> pkg-config --cflags plymouth-1
> [/code]
> returns "-I/usr/include/plymouth-1", so you will need to add the extra ply/
> or plybootsplash/ in your #include lines. Otherwise you can simply specify
> them manually at the terminal as such:
We should probably fix the in-tree plugins to do ply/ too, or fix the
pkg-config file to include the ply/.
There's no reason their should be an inconsistency here.
> You will need to remove the include "config.h" from your plugin. Since
> you're working separate of the git source, it isn't really needed, but it's
> still good to take a look at config.h to familiarize yourself with whats in
> there.
Maybe we should wrap the #include "config.h" with
#ifdef HAVE_CONFIG_H / #endif bits . . .
> You will also need to add several #defines with the headers at the top of
> the plugin and manually specify the paths to the required files there. If
> you are wondering what these #defines originally were, then look at the
> Makefile
> that was generated for the splash in the git source.
So for this, we should probably move the #defines to a header file we ship,
so plugins can just #include it. Or make them functions instead of defines.
Or we could make them pkg-config variables.
--Ray
------------------------------
Message: 3
Date: Mon, 16 Mar 2009 10:58:27 -0400
From: Ray Strode <[email protected]>
Subject: Re: Gradient Framebuffer Fill Bug?
To: Jonathan Greig <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> I've been testing the gradient framebuffer filling function out some. It
> doesn't work as expected. Below is a modified snipplet from the spinfinity
> plugin demonstrating this. The gradient should start at 80% height and stop
> at the bottom of the screen. What the actual result is a cropped area of a
> fullscreen gradient.
I think the idea there is so if only a small rectangular part of a big
full screen gradient gets updated, we can just pass in the x, y, width
and height of that area and it will just fill in the part of the
background gradient that needs to get updated.
That's certainly not intuitive behavior though, it seems like it would
be worth fixing. Looking at the gradient code, I guess we need to
- compute the steps based on area, not buffer->area.
- figure out how to make sure the noises generated over multiple runs
with different x, y, width, height values is generated in the same
places. I guess we could pregenerated a noise map or something along
those lines instead of depending on the srand() hack that's there
now.
> Also, I noticed that there are some odd bars appearing near the top of the
> screen that are a little glitchy. Not sure if this is due to testing the
> plugin without rebooting or what.
Not sure. note on_erase can get called for other than full screen
updates. that might have something to do with it. If you reboot does
the problem go away?
If you file this as a bug report on bugs.freedesktop.org, I can try to
look into these things, or if you want to figure out what's going on,
that'd be good too.
--Ray
------------------------------
Message: 4
Date: Mon, 16 Mar 2009 11:01:33 -0400
From: Ray Strode <[email protected]>
Subject: Re: Spinfinity Plugin Simple 1 Line Fix
To: Jonathan Greig <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Sun, Mar 15, 2009 at 5:59 AM, Jonathan Greig <[email protected]> wrote:
> In the spinfinity plugin, in the stop_animation function, should look like
> this:
>
> #ifdef ENABLE_FADE_OUT
> int i;
> ? for (i = 0; i < 10; i++)
Thanks, fixed.
--Ray
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 6, Issue 8
**************************************
