One issue with the two-step plugin is that during the initial boot
progress the frames can be updated several seconds apart from each
other. This can look jumpy. We can now optionally fade between
the frames to make the experience be a little smoother.
The OLPC theme looks best when it's white, so we need to be able to
specify the background color from the theme. If the theme doesn't
specify a background color, we fall back to the old behavior of using
the distro default.
Some of the plugins (well, the glow plugin) would be a lot more
versatile if they could be reused for multiple splashes with different
images.
This commit splits boot splashes into two parts, the plugin engine which
does all the dirty work, and the theme which says which plugin to use
and optionally how the plugin should work (using plugin specific
key/value pairs)
This is a very lame keyfile parser. We'll be able to use it to load
some metadata about the plugins.
The idea is that plugins will shift to being engines that can be
leveraged from multiple splash themes. This way, for instance, the glow
plugin (which will be renamed) can be used to implement several
splashes.
Adds ply-list.c/h to all tests automake files which use ply-logger.c.
Adds PLYMOUTH_TIME_DIRECTORY/PLUGIN/THEME_PATH when ply-boot-splash.c is used.
Adds PLY_BOOT_SPLASH_MODE_BOOT_UP to the ply_boot_splash_show call.
This will be useful for debug purposes.
It's implemented by adding the concept of
"filters" to the logger code. Each time a message
is logged it is passed through all registered
filter handlers and then the output of the filters
are what is actually logged.
In this case, we pass the messages through verbatim,
but also redirect them to a debug buffer.
We only do this redirection when plymouth:debug is
used.
We used to run and remove timeouts in a loop. This
breaks the case where the dispatched timeout handler
removes the timeout itself.
We fix it by making timeout handling a two pass thing.
First we find which handlers need to be dispatched,
and move them to their own list. Then we run through
the new list and dispatch the handlers.
init does two rounds of killing at shutdown:
a round of SIGTERMs and a round of SIGKILLs.
We want to stay alive until the SIGKILL round
so we ignore the SIGTERM signal.
Plymouth client ask-for-password and ask-question commands have their option
"--pause-progress" changed to "--dont-pause-progress". By default progress is
paused and "--dont-pause-progress" has to be supplied to not pause.
We used "rhgb" because that's what Fedora users were used to
instinctively removing when graphical boot messes up. This
isn't a very intuitive (or very upstream-y) name though.
Now we check for "rhgb" or "splash"
If we don't then someone during boot up may change
out from raw when we aren't looking.
Maybe we should use TIOCSLCKTRMIOS to prevent that
from happening? Or maybe we should bypass the tty
for input entirely and use evdev?
Previously ply-entry was crashing with an assertion "entry->loop == NULL"
whenever the entry was updated. The change is basicly a copy of the working
version from spinfinity.
This will play a sequence of images from beginning to end at
a fixed frame rate. It differs from the throbber in that it starts
at the 0th image and does not repeat.
With integer options there's no obvious value to mean "unset" like there is for
string types (and to a lesser extent boolean types), so this commit
adds a mechanism.
