This reverts commit 126345af87.
If plymouth show-splash blocks until the splash screen is shown,
then systemd-ask-for-password-plymouth will block for 5 seconds
before asking for the password (which would have canceled the 5
second delay if it weren't for the dependency on plymouth-start.service)
Briefly, the two-step plugin would delay showing itself
for a few seconds (in case the machine boots quickly).
That got reverted, because i'm not convinced any longer
that doing it in the splash is the right level. Also,
the implementation had various bugs causing the delay
to show up at the wrong time.
This commit makes it a daemon option instead.
This makes it easier to apply to all themes, and also makes it
so the admin can opt-out without changing themes.
Right now we clear is_shown after calling hide_splash in a couple
of places. It makes more sense to clear this flag in one place,
in hide_splash, rather than duplicating code.
There's no reason to load them lazily, and when
we extend the functions to add a theme delay setting,
we're going to want to have the settings available as early as
possible.
Right now we read /usr/share/plymouthd/plymouthd.defaults
and /etc/plymouth/plymouthd.conf to find the configured splash
screen. The two functions that do this are basically copy-and-paste
of each other.
This commits splits some of the duplicated code out into a common
function for clarity. Doing this also helps to facilitate adding
more configuration options, which we'll need to do in the future
to support a global start up delay.
If the client asks for a password and we don't have a splash
screen, we currently reply with a NOANSWER reply which makes
the client ask for the password instead. This is so ask-for-password
requests that come up when plymouthd isn't controlling the tty can be
handled.
These days show-splash requests are asynchronous and so a splash screen
might not be around "right now" but will be around in the near
future. In these cases, we really want plymouth to handle asking for
the password, because it's going to take control of the tty imminently,
so the client won't able able to ask for the password (and, of course,
we'd rather the splash ask for the password anyway, since it's a better
user experience)
This commit checks if there's a looming show splash request. If there
is, it avoids doing the NOANSWER reply and instead just sits tight
waiting for the splash to come up and the user to enter the password.
Right now if a client calls show-splash it will return
immediately, before the splash screen may be necessarily
shown.
From this point on, init thinks the splash screen is up
and does things like asking for a password, which will
subsequently fail.
This commit makes 'plymouth show-splash' block until the
splash screen is actually shown.
This reverts commits 540ae58fe0 and 17976ac538.
I want to implement the feature more generally, and the current
implementation has bugs when toggling to details and back.
The libply-splash-core library provides functions for controlling the
input and output of the splash screen.
Recently it gained support for device enumeration from udev using the
libudev library. When that support was added, the linker and compiler
flags of the plymouthd binary were augmented, instead of the the
libply-splash-core library directly. That broke the build on some
systems.
This commit moves the linker and compiler flags to the correct place.
We watch for udev events even after forcing fall back, so we need to
make sure we don't allocate two seats for the local console if we
fallback then get a late event.
Recently, loading a splash was separated from showing the
splash. This ends up breaking fall back to the text splash,
because we don't know if we need to fall back until after
the default splash fails to show.
This commit recombines loading with showing.
Right now, we'll wait indefinitely for graphics devices to show up
before showing the splash screen.
This means text splashes don't get shown, at all.
This commit changes the initial scan for graphics devices, to
include uninitialized ones. If there aren't any, then we fall
back. If there are some, we know an add event will be coming, so
we don't fall back. We still handle already initialized devices
right away.
We need to make sure udevd is started before plymouthd since we
need to know that "queue is empty" means "coldplug complete" not
"coldplug hasn't started yet".
A certain class of machines don't work in plymouth because
they draw the kernel console to /dev/dri/card1 instead of
/dev/dri/card2.
This branch fixes that, by adding support for querying udev
to determine the available drm devices.
As part of this effort, some clean up was performed:
1) a bunch of bit rotted tests were removed
2) large chunks of code were moved from main.c to helper
objects implemented in other files.
3) Other parts of main.c were moved around or refactored
so they were easier to read.
Based on work from Kevin Murphy <kemurphy.cmu@gmail.com>
https://bugs.freedesktop.org/show_bug.cgi?id=25943
Since we're monitoring udev explicitly now, we have no
need to block the client show-splash request until graphics
devices settle.
This commit removes the udevadm calls from plymouth-start.service.
We don't want to use udev for device enumeration if:
1) DISPLAY is set (since we're going to use the X11 renderer)
2) if it's disabled explicitly on the kernel command line
This commit adds support for those two things.
At the moment, we hardcode /dev/dri/card0 for the DRM device.
This works well enough in the lion's share of cases, but there are cases
where it falls over. Namely, machines with multiple GPUs, such as
optimus hardware, sometimes end up with the kernel fb console going to
/dev/dri/card1.
Rather than trying /dev/dri/card0 then /dev/dri/card1 etc in succession,
this commit, instead, adds support for querying udev for the
information.
It's useful to be able to figure out which renderer a given renderer
is, by examining the device that is associated with it.
This commit adds and accessor function to return the device that
was passed to ply_renderer_new.
At the moment, it does not return the device name if NULL was passed
to the constructor and the device was figured out automatically. A
future commit may add that ability if it becomes necessary.
We're going to want to support multiple graphics devices, as
specified by udev.
This first commit, merely adds the libudev dependency to the
build goo.
If there are multiple DRM devices, only one
can really be reading from the terminal at a time.
We currently punt this issue by ignoring all but
the first drm device.
In preparation for supporting more than one DRM device,
we need to come up with a solution.
This commit changes the DRM renderer plugin to allow getting
a NULL terminal. In this way, we can assign the terminal to
one of the DRM cards, but still output to the others.
Note, we never pass NULL for a terminal yet, that comes later.
Now that we have a class for managing our seats, let's use it.
This gets a lot of the nitty gritty logic out of main.c and
paves the way for us to do smartcard device management going
forward.
There's quite a bit of logic for managing input and output in
main.c right now. That code is already a bit too complicated,
but will get even more complicated going forward if we want
to add udev support, etc.
In an effort to keep things from getting too unwieldly, this
commit breaks out a lot of the logic into a new
ply-device-manager class.
A subsequent commit will make main.c use the new class.
Everywhere we call show_theme we call show_messages immediately,
afterward.
Since showing the messages on the theme is arguable part of showing
it, this commit moves show_messages into the show_theme function.
Right now show_default_splash and show_detailed_splash,
load the relevant splash and then show it.
This commit drops the "show" part and renames the functions to
load_default_splash and load_detailed_splash, respectively.
It, of course, also updates the callers to call show_theme
explicitly.
This refactorization will make it easier to later move device
management out of main.c
Now that main.c is attaching seat objects to the boot splash,
instead of the seat's individual components, we can drop the
apis that allow doing things piecewise.
ply_boot_splash_t currently gets notified about displays and keyboard
objects to pass along to the splash plugins.
Now that we have a ply_seat_t object that can encapsulate display
and keyboard objects, we should add support to ply_boot_splash_t for
using it.
This commit does that. For now, it does it without changing the plugin
interface (which is still in terms of displays and keyboards).
Note, this commit only adds support for seat objects to
ply_boot_splash_t. It doesn't actually change any of the calling code
to use that support. That will come in a subsequent commit.
Right now we maintain parallel lists of displays in several different
layers of code.
This commit introduces a "seat" object to encapsulate a set of displays,
and associated input device.
A subsequently commit will actually change the code over to use the
seat object.
start_boot_splash is a convenience function that's going to
get in the way in the future. It also has the annoying
"boolean argument" problem that load_theme had.
This commit gets rid of start_boot_splash entirely.
load_theme currently takes a boolean that if true, will
make it load the built-in "details" plugin if the main plugin
fails to load.
Boolean arguments are hard to read, so this commit drops it.
We already have the details theme "built" in, so there's
little point in loading the details.so plugin when we want
details internally.
This commit fixes that.
Right now start_boot_splash loads the theme, then
shows it.
It's going to be useful in the future to preload the
theme, so this commit breaks the two operations out
into two functions, load_theme and show_theme,
and makes start_boot_splash just call those two
functions.
