This commit adds a new program, plymouth-upstart-bridge,
the listens for upstart state changes and sends them to plymouth,
or prints them out as appropriate.
This patch adds the respective configure options to make it possible to
disable libdrm_intel, libdrm_radeon, libdrm_nouveau, and libkms
independently from each other.
https://bugs.freedesktop.org/show_bug.cgi?id=29804
The logofile by default is $datadir/plymouth.png
$datadir contains a reference to $datarootdir, so
we need to preexpand the variable in configure, for
the right value to get written to plymouth-populate-initrd.
When not installing in system root, the populate initrd script would not
install the client or daemon due to the paths being hardcoded.
Environmental variables are also now available to override the defaults.
The viewer is useful for seeing boot messages after boot up.
It does this by showing a notification icon in the event there
is a problem during boot.
Notification icons aren't as en vogue as they once were, however.
Ideally, we would have a more structured and semantically aware
way to deal with specific boot problems.
This commit turns the icon off by default. It can still be built
with a --with-log-viewer
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=30724
Reported By: William Jon McCann <william.jon.mccann@gmail.com>
This commit adds most of the pieces in place to use libkms, a
library by Jakob Bornecrantz, that abstracts the drm drivers
behind a common api.
Right now, we only fallback to libkms if the existing
backends won't work for the configured hardware.
In theory, this will give us pretty boot in virtual
machines, since libkms has support for the vmwgfx drm driver.
Aside from vmwgfx, libkms also supports intel and nouveau right
now. When it supports radeon, too, I'll probably switch to
using libkms by default instead of as a fallback. Eventually,
I'd like to drop all the non-libkms backend bits and the whole
driver vtable abstraction thing from plymouth completely.
This commit is just a copy-and-paste of one of the existing
drm backend files, with changes made to accomodate the libkms
api. I haven't actually tested it, yet, so it will probably
need changes after I get a chance to do that.
On my system, some headers seem to be stuffed in /usr/include/libdrm
and other headers seem to be stuffed in /usr/include/drm .
I think the ultimate upstream goal is for everything to be in
/usr/include/libdrm but my system seems to be in some transition state.
My pkgconfig files only point me to one of the directories, so add some
heuristics to find the other one.
Right now we figure out the default theme via a symlink.
This apprach is very simple, but is also a little cumbersome.
It means as the default theme is changed around we have to move
the symlink around.
The symlink is in /usr. We really shouldn't be mucking with
/usr when changing defaults.
This commit checks the filesystem for two config files:
/usr/share/plymouth/plymouthd.defaults
and
/etc/plymouth/plymouthd.conf
The first one is for distributions to use. This is how they can
manage which splash to show from release to release.
The second one is for system administrators. This is how they
can override distribution policy.
We don't actually ship these files yet. In the mean time,
(and even after for the forseeable future) the old symlink method
will still work.
The scripts hard-coded the paths for LIBEXECDIR and DATADIR, unless
passed as environment variables. Instead of doing this, which breaks
if plymouth is installed outside of /usr, set these derived from the
configure $libexecdir and $datadir variables just as we do for
pkg-config, etc.
Since we use so many variables, it makes more sense to generate these
scripts from config.status rather than having special Makefile rules
for them.
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.
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 renderer is useful for testing plymouth splash
plugins without leaving X. It simulates a multi-head
display by creating two X windows each representing
one monitor.
Much of this code comes directly from ply-frame-buffer in libply,
but shoehorned to fit into the renderer plugin interface.
One improvement over the old code is it tracks VT changes, and
stops drawing when the wrong VT is active.
We want the .pc file to have the full expanded paths,
so it doesn't end up with unexpanded datarootdir, etc.
To achieve this we copy in the AS_AC_EXPAND macro
that thomasvs did a while ago.
Automake 1.11 has a new feature that's all the rage these days.
It makes build output look like:
CC plymouthd-ply-boot-server.o
CC plymouthd-ply-boot-splash.o
CC plymouthd-main.o
CCLD plymouthd
instead of the usual field gcc gunk.
This commit turns it on for those who have it.
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.
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)