When communicating with Plymouth from another process, it's
inconvenient to have to keep spawning the plymouth client binary
and keeping track of it - not to mention slow.
It's far cleaner to be able to link to the same boot client code
that the plymouth binary does, and communicate directly.
Place that code in a new libply-boot-client library, and install
the headers along with it.
We currently reconnect the terminal object on tty disconnects,
but we don't rewatch the keyboard. A disconnect will invalidate
the fd watch, so we need to handle it to prevent crashes.
There are times when plymouthd isn't in a position to ask for
the password (for instance, if the initramfs is about to run
init=/bin/bash or something). In those cases, any password
requests need to be handled by the client.
Even if we can't contact the daemon, we should still run the
ask-for-password command. This is because the command may
do things important for boot up to continue like unlocking
the root partition.
Previously the Math.Int function converted to int and back to double.
The floor function works larger than those represented by integers and it
correctly handles NaN and Inf.
Right now, plymouthd links against libplybootsplash which links
against libpng. Only graphical splashes use libpng, but it's
always pulled in.
This merge splits libplybootsplash into two libraries: the core
bits, and the extractable graphical bits. Only the graphical splashes
link against the latter library. This way server installations can
get plymouth without pulling in libpng. This will reduce the amount
of security errata deployed to those server installations.
Splashes aren't just shown for "boot" so including "boot" in
the name isn't right. Also, right now we link against libpng
even if we don't have any splash that uses it. This is the first
step toward making libpng only get linked to graphical splashes.
We'll need to move the graphical bits to their own library to
complete the process.
This merges the "man-page" branch to master.
Thanks to Adrian Glaubitz we now have a man page for plymouth.
This is a good start to documenting the basics of plymouth.
We'll eventually need more comprehensive reference documentation
before 1.0 is released, and now we have some of the ground work
(a docs/ directory) for that.
They weren't completely accurate, you don't need to reinstall
grub after editing its config, since it has built-in filesystem
drivers. Also, those details very from system to system, so we
should probably just leave it out.
We don't want to provide a history of what distributions
used before plymouth, because that history could get long,
isn't super relevant, and will add noise for a users looking
for help (they probably only care about their distributions,
not others).
When running new, unfamiliar commands I usually invoke them with
--help to see what options they have. For plymouth-set-default-theme,
there is no --help option which I find a bit confusing, especially
since the usage is not straight-forward.
There is now an additional function "show_help" which displays an
help output when invoking plymouth-set-default-theme with --help.
Previously we drew two overlapping labels, one in black and one in white, to
make sure it was vsible on all backgrounds. Now we can pick an appropreate
color for each theme. The default is white. If changing the label color once it
has been shown, it will redraw that part of the screen.
Although the windows are set up to in a reasonable default configuration, the
themes may align the windows differently to not crop some important elements.
The Window.SetX and SetY allow positioning the window anywhere on the canvas.
Use this sparingly as it induces a full refresh of all screens.
If there is a desire to have totally different scenes, the second window can be
positioned somewhere far away so there is overlap and a complete different set
of sprites is used. Another sensible configuration is to have the screens side
by side and allow sprites to span the gap. Remember to create password dialogs
for each screen as not all may be visible.
When multiple displays were introduced, each display had its own script plugin
instance. This made things easy as the scripts would not have to be rewritten
for multiple screens. Unfortunately this also meant that each image was loaded
multiple times, and the scripts consumed much more processing power.
Additionally the scripts were not aware of each other.
This patch allows a single script instance to control multiple displays while
maintaining reasonable backward compatibility. All sprites are placed on a
virtual canvas. Displays (or windows) then expose parts of this canvas to the
user.
As a default, window 0 is placed at 0,0. Further windows are placed on top of
the window 0 area matching the centre point so the password dialog (which is
placed in the centre) is visible on all windows. If you target window 0 only
and you place dialogs in the middle of the screen, then everything should work
fine.
Window.GetWidth/GetHeight now takes a window number (if none supplied it will
assume 0). If it replies a NULL, then you accessed beyond the end of the
window set.
Stable sort sorts but does not change the order of elements which are equal.
This is important in the sprite based plugins where if the level of the sprites
is equal because it may be unimportant which is on top, changing the order
between frames looks bad.
The renderers commit the rectangles derived from the region in a random order.
This gives some tearing as the screen is displayed with a random regions in
their new state. The change sorts the list of rectangles according to their Y
value to commit them from top to bottom. This gives fewer tear lines.
Scott James Remnant
Ray Strode
Charlie Brej
Scott James Remnant
Adrian Glaubitz