This patch adding support for operation log messages and updating upstart
bridge code to use it. This is usefull for verbose log output (e.g daemon
starting, stopping).
Example:
Register operation ssh:
$ plymouth register-operation --operation-id=ssh --name='Starting OpenSSH server ssh'
Set state of operation ssh to wait:
$ plymouth update --operation-id=ssh --status="wait"
Details plugin will show: 'Starting OpenSSH server ssh... [wait]'
Set state of operation ssh to done:
$ plymouth update --operation-id=ssh --status="done"
Details plugin will show: 'Starting OpenSSH server ssh... [done]'
Unregister operation ssh:
$ plymouth unregister-operation --operation-id=ssh
https://bugs.freedesktop.org/show_bug.cgi?id=77389
This reverts commit 8c267e9a3b.
I think this patch was accidentally pushed, since the commit date is
years older than the push date, and it seems to overlap in already
existing pid-file functionality.
If we actually do need this commit we can always add it back of course.
If we have a pixel display, the renderer will handle opening the
associated terminal. but if we don't have a pixel display, something
needs to open the terminal.
This commit adds code to do that.
we need to call update display any time a splash is shown,
because there may be a pending password request.
The code attempted to do this in show_splash, but did it before
the splash was assigned to running state, so function was a noop.
This commit moves it a little later in code after the splash is
properly assigned.
Right now we use the heuristic, "more than one entry in
/sys/class/tty/console/active" to mean "has serial consoles".
We used to use the heuristic "file has more than tty0 in it".
The older heuristic is more accurate because a user may have
console=ttyS0 without console=tty0 on the kernel command line.
We never want to use a /dev/fb device if a DRM device will work instead
(since it supports multi-monitor, isn't a legacy interface, etc)
Unfortunately, right now plymouthd notices efifb at early start up,
see's there is no DRM device associated with it and chooses it for
the main display, which causes all sort of problems.
This commit defers using /dev/fb devices until after udev settles.
Right now, we piggyback off fb subsystem events to know whether or
not a drm device is hotplugged (since all drm devices have fb devices
for backward compat).
This commit makes drm and fb processing more independent, so we don't
rely on the compat device being available for drm hotplug to work..
We used to use plymouth:debug to enable debugging in the
plymouth daemon, and changed it to plymouth.debug to be more
consistent with other users of the kernel command line.
We neglected to update the client to support the new format
though. This commit does that.
Currently plymouth stays in control of the terminal
after hide-splash. This is wrong. Once plymouth is
hidden, the terminal should be free to use for other
programs.
This commit makes sure we free up the terminal on
hide splash.
This fixes a race/crash where plymouthd get deactivated
right before the show timer fires and it tries to
show itself after things have been torn down.
It was a weird to show something in a function called "cancel..show"
Instead move the logic to the one caller that actually needed that
functionality (on_ask_for_password)
If plymouth is configured --with-system-root-install=no then the
systemd unitd files will write the paths of plymouth and plymouthd
relative to /usr . The script currently hardcodes installing them
to the initrd's /
This commit makes sure they get placed on the same part of the of
the initrd filesystem as systemd expects to find them.
https://bugs.freedesktop.org/show_bug.cgi?id=74174
If a seat gets opened with a renderer type of AUTO, and the renderer
fails to open, then it's okay and expected to proceed without a
renderer (and just use the terminal). The code attempted to do this
but failed to nullify the seat->renderer object, so it ended up
going down the renderer-active code path.
This commit fixes that.
There's no point in waiting for a graphics device if details are
forced, and we shouldn't ever delay showing details. If details
are requested, we shouldn't be hiding them.
The details plugin is "built in" to the plymouthd binary, so
it's always available even if the details module isn't installed
(say /usr isn't mounted yet or something)
Unfortunately, this feature isn't working because plymouthd isn't
built with -rdynamic (except for in my local CFLAGS).
This commit fixes the makefile goo accordingly.
At the moment we add pixel displays if we can, or
text displays if we can't add pixel displays.
We need to always add text displays, otherwise, the
text splash won't work when explicitly configured by
the user.
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.
