When transforming the output of libpng to ARG32 with pre-multiplied
alpha, only do the multiplications if the pixel isn't opaque. Otherwise
plymouth is just applying a very complicated identity function.
https://bugs.freedesktop.org/show_bug.cgi?id=87105
If the source buffer is known to be fully opaque and the fill is done at
full opacity, simply memcpy the data row-by-row instead of iterating over
every pixel and blending it with the target buffer.
This could be optimized more, in the future, in some cases, by memcpy of
the entire block instead of row-by-row.
https://bugs.freedesktop.org/show_bug.cgi?id=87105
Pixel buffers contain ARGB32 data. Add functionality to mark a buffer as
containing only fully opaque pixels. This functionality can be used by
rendering functions to be able to optimize drawing of such buffers.
https://bugs.freedesktop.org/show_bug.cgi?id=87105
We only support the generic driver now, and it doesn't
support mapping the console.
This commit removes the supports_mapping_console boolean,
and any code that checks for console mapping.
systemd isn't necessarily in the buildroot at the time that plymouth
gets built, so autodetection of the unitdir from pkgconfig isn't
necessarily feasible.
This commit adds a new option to configure, --with-systemdunitdir,
that lets distros specify the unit directory manually.
https://bugs.gentoo.org/show_bug.cgi?id=543712
In the case of Endless, we have a very fluid active bootup animation
that looks quite excellent for turning the computer on, but when turning
it off or restarting, it's sort of awkward to have the same animation
play. For our use case, we want to simply show our watermark.
animation->frame_area isn't filled in until the timeout, but clients
might draw it beforehand. Since animation->frame_area isn't used
anywhere else and we already have the x/y values in animation->x/y,
just use those and remove animation->frame_area.
If the drm device failed to work, then fall back to the fb device.
Right now, we ignore fb devices that have associated drm devices.
This may fix vmwgfx.
Currently, the animation object 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 animation.
In case none of them are, we'll end up not adding any frames, so we
should not report a successful load.
This is like commit 741b545868 but for
animation objects instead of throbber objects.
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.
