systemd doesn't block waiting for a reply to its update request, since
it would pointlessly slow down boot up.
This commit makes sure we don't bother logging that case.
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)
