This is an initial support for the scripted plugin. There are _many_ FIXMEs
and the whole code is reather unstable. The formatting is completely incorrect
and will be changed soon. There are scripts which are converted using a perl
to an C embeddable string.
These are used to feed the keyboard input a single character at a time, to
determine the number of bullets in the password dialogue and process backspaes.
When drawing the gradient, rather than creating each dithered pixel, a block
of 8 pixels is created and copied repeatedly to the target. So long as the
number of noise bits is low and the random number generator is good, no
repetition is visible.
In some plugins about 80% of time is spent in the random number generation
functions. These are used to create the dithering noise to stop the banding in
the gradient functions.
The simpler version is an adaptation of a linear feedback register which
creates a pseudo random sequence repeating every 4,194,303 generations.
When adding areas to be flushed, the algorithm now looks for partial overlap
with existing areas and if found it either: throws away an area as it is fully
overlapped, reduces the area to remove the overlap or breaks the area into two
skirt around the area already in the list.
The algorithm does does not scale particularly well when there are more than 30
areas stacked with each being partly (but not fully) overlapped by others. This
creates a large list of small areas to check against which could eventually
become counter productive.
One advantage of the previous bounding box approach to flushing
is overlapping flush areas wouldn't get flushed multiple times.
This commit tries to identify overlapping flush areas and eliminate
them. It's not perfect though.
A better approach might be to store a sorted tree of areas to be
flushed, and walk the tree when adding new flush areas to quickly find
overlapping areas. Then we'd split each area into two or more new areas
to avoid overlaps.
Previously we would always aggregate flush areas together even
if they were disjoint and far apart. That meant that if two
images on opposites sides of the screen were updated in one
frame, then the entire screen would get redrawn.
We now track flush areas in a list, instead of a bounding box.
Before this commit it would always flush the area_to_flush
area. Now the interface allows flushing arbitrary areas. This
change paves the way for us to flush multiple disjoint areas
at one time.
The trigger always needs to get pulled so that the
daemon knows that it can quit. Previously, we weren't
pulling it if two-step was already idle. This meant that
plymouthd never quit.
The merge fade merges the two frames before drawing them to the framebuffer.
This makes a smooth transition between areas with partly transparent pixels or
areas in later frames becoming trasparent. This is set as the default on the
"glow" theme.
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.
