Currently, the throbber will report success when assets are *found* in
the directory. When loading those assets, code will apply more checks to
determine if the assets are meant for the throbber.
In case none of them are, we'll end up not adding any frames, so we
should not report a successful load.
Currently, the throbber will report a successful load when zero assets
are loaded. Change it so that zero assets do not result in a
successfully loaded throbber.
This is similar to commit 3d7f4fe441 but
for throbber objects instead of animation objects.
All the ply_read* functions assume the socket is doing blocking reads,
so opening unix sockets in non-blocking mode doesn't seem the best idea.
Specifically, this was causing ask-password to fail to read the response
at times as it got a -EAGAIN back from read rather then data.
The script plugin hardcodes an FPS value of 50, which for some themes
and various devices is a bit much. Add a new function
(Plymouth.SetRefreshRate) which sets the rate at which the
RefreshFunction gets called so each script theme can determine their most
appropriate rate.
https://bugs.freedesktop.org/show_bug.cgi?id=86247
plymouthd runs in a particular mode "boot" "shutdown" "updates" at any
given time. Likewise, the plymouth splash object also takes a mode.
These modes map 1-to-1 with each other, and there is more than one place
in the code where we need to get the splash mode from the overall mode.
This commit adds a helper function to perform this translation, and
cleans up the places where the wrong mode type is used or the
translation performed is incomplete.
We assume /proc/cmdline will be no more than 512 bytes (including NUL).
It can actually be 4096 bytes (excluding NUL).
This commit makes sure we allocate enough space for it and its NUL.
This is just like the previous fix for the daemon, but for the client,
now.
We assume /proc/cmdline will be no more than 512 bytes (including NUL).
It can actually be 4096 bytes (excluding NUL).
This commit makes sure we allocate enough space for it and its NUL.
At the moment, we don't bother showing the splash
screen if init=/bin/sh since we assume the user
wants to be see the shell prompt.
The problem is, since we don't show a splash screen
we don't handle LUKS in the initrd.
This commit makes us show the splash for the duration
of the initrd but quit on switch root.
This reverts commit 7adb50c267.
The .service files are already statically enabled, adding the Install
section and the WantedBy option is useless
Conflicts:
systemd-units/plymouth-quit-wait.service.in
https://bugs.freedesktop.org/show_bug.cgi?id=80048
For some reason in commit 113526408c
I commited the sequence \x25\x96\xa0 in place of the block character
that was there before. I don't know where I got \x25 from, but it's
not right (and couldn't even be right since the high order bit isn't
set which is a requirement for the first byte in multi-byte utf-8
sequences).
This commit uses \xe2 instead which I got from doing:
$ echo ■ | xxd
0000000: e296 a00a ....
We can end up in a situation where a seat object doesn't have a terminal
associated with it. In that case we shouldn't crash, but continue on
with no input available for that seat.
https://bugs.freedesktop.org/show_bug.cgi?id=80553
Due to removed interfaces since 0.8.8:
ply_boot_splash_set_keyboard
ply_boot_splash_unset_keyboard
ply_boot_splash_add_pixel_display
ply_boot_splash_remove_pixel_display
ply_boot_splash_add_text_display
ply_boot_splash_remove_text_display
And a bunch of new ones added.
plymouth-quit-wait.service is a synchronization point that
other services tie into, so they know when boot is finished
and the splash is down.
Unfortunately, in cases where the boot stalls, the last thing
users see is:
Starting Wait for Plymouth Boot Screen to Quit...
and then assume the problem is with the boot splash.
This commit makes the description less finger-pointy.
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.
