ply_kernel_command_line_get_string_after_prefix returns the rest of
the commandline after the passed in prefix. When parsing key=value parts
of the commandline, we really only want the value part and stop at the
whitespace separating it from other kernel commandline arguments.
This commit adds a new helper which returns a strdup-ed string containing
just the value; instead of the entire rest of the kernel commandline.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 28 Sep 2019 12:29:02 +0000 (14:29 +0200)]
two-step: Merge show_password_prompt and show_prompt into 1 function
These 2 functions were doing almost the same. Move the setting of the
entry text or bullet count into view_show_prompt were it belongs and
merge these 2 functions into 1 function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 28 Sep 2019 10:05:11 +0000 (12:05 +0200)]
twp-step: Remove superflous is_hidden / is_stopped checks from on_draw
Remove superflous is_hidden / is_stopped checks from our on_draw
handler. In all 3 cases the is_hidden / is_stopped check guards
a draw_area call, but the draw_area calls themselves contain the
same check, so it checking this in on_draw is not necessary.
Also note that we are already not doing such a check for e.g. the
progress_bar so lets be consistent and remove the check everywhere.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 28 Sep 2019 09:59:47 +0000 (11:59 +0200)]
two-step: Cleanup stop_animation function
Cleanup the stop_animation function:
- Remove the trigger argument as all callers pass NULL
- Remove the logging of "hiding progress animation" we already log a
generic "stopping animation" message and we do not log such a message
for the other animated controls, so remove this one for consistency
- Add a NULL pointer check for view->end_animation, as this can actually
be NULL when view_load_end_animation fails
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 26 Sep 2019 13:59:38 +0000 (15:59 +0200)]
themes: Move spinifity from the throbgress splash to the two-step splash
At one point in time the two-step splash plugin was forked from the
throbgress splash. Since then the two-step plugin has grown to be more
flexible / configurable.
The two-step plugin is now flexible enough that with the right config
it can mimick the throbgress plugin. Moving the spinifity theme to
use the two-step plugin allows us to remove the throbgress plugin,
removing the code duplication between the 2 plugins.
An added advantage of this is that the two-step plugin has more functionality,
such as capslock indicator support for the password dialog.
Note the throbber-??.png images were modified to add 24 transparant rows at
the top, to get the extra hardcoded throbber-height / 2 space which the
throbgress plugin added between the throbber and the header-image, this
was done automatically using the following command:
convert old.png -background transparent -gravity northwest -splice 0x24 new.png
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 25 Sep 2019 16:56:34 +0000 (18:56 +0200)]
two-step: Add new UseAnimation setting
Until now we have been disabling the animations when the theme specifies
that a progress-bar should be drawn for the current mode.
This commit adds a new UseAnimation setting which defaults to
!UseProgressBar to preserve the old behavior if UseAnimation is not
set by the theme.
This makes two-step more flexible. Specifically it will allow implementing
the spinfinity theme using two-step; and spinifinity is the only user of
the throbgress plugin, so this will allow removal of that plugin.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 25 Sep 2019 20:36:47 +0000 (22:36 +0200)]
two-step: Make progress-bar location and size configurable
This commit makes the progress-bar location configurable seperately from
the animation location and it makes the progress-bar size configurable
instead of hardcoding it.
This makes two-step more flexible. Specifically it will allow implementing
the spinfinity theme using two-step; and spinifinity is the only user of
the throbgress plugin, so this will allow removal of that plugin.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 26 Sep 2019 08:37:07 +0000 (10:37 +0200)]
two-step: Fix progress-bar not hiding when it should
Before this commit we were not hiding the progress-bar when starting the
end-animation nor when stop_animation gets called. This adds the 2 missing
hide calls, making the handling of the progress-bar identical to that of
the progress-animation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 25 Sep 2019 22:52:48 +0000 (00:52 +0200)]
two-step: Fix progress-bar not updating on normal boot
We were only calling ply_progress_bar_set_percent_done from the
system_update callback and not from the on_boot_progress callback.
This commit fixes this by adding the missing calls for this to
update_progress_animation and it makes system_update use
update_progress_animation instead of duplicating the code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 26 Sep 2019 08:15:23 +0000 (10:15 +0200)]
two-step: Fold ply_progress_animation_hide call into view_start_end_animation
We should always disable (hide) the progress-animation when
starting the end-animation. Instead of having all callers of
view_start_end_animation do this themselves, do it at the beginning
of view_start_end_animation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 19 Sep 2019 14:05:17 +0000 (16:05 +0200)]
label: Properly deal with pixel-buffers with non-upright device_rotation
Fix the label plugin rendering garbled (wrong pitch) top to bottom text,
instead of proper left to right text when the pixel-buffer has a
device-rotation of rotate-clockwise or rotate-counter-clockwise.
Hans de Goede [Fri, 6 Sep 2019 15:21:45 +0000 (17:21 +0200)]
ply-device-manager: De-activate and close renderer on device hot unplug
When a device gets hot unplugged, we should de-activate and close the
renderer before freeing it.
Speficially this fixes a problem where plymouth's display "freezes" when
used with AMD GPUs which can be handled by both the radeon or the amdgpu
kms driver and the user has added kernel commandline options to prefer
the amdgpu driver. In this case the following happens:
1) radeon driver gets loaded, creates /dev/dri/card0 generating a udev
"add /dev/dri/card0" event.
2) radeon driver's "load" method checks if it should bind, comes to the
conclusion it should not, causing the probe of the device to be
aborted and /dev/dri/card0 to be unregistered generating a udev
"remove /dev/dri/card0" event
3) amdgpu driver loads, creates /dev/dri/card0 generating another udev
"add /dev/dri/card0" event.
4) plymouth loads while udev is still catching up with kernel events,
plymouth sees the first "add" event opens /dev/dri/card0 (which is
already managed by amdgpu at this time) finds outputs, shows splash
5) plymouth gets the "remove" events tears down the renderer, but
since deactivate and close were not called before this commit,
plymouth keeps the master rights attached to the old-fd which is
leaked at this point
6) plymouth gets the second "add" event brings everything back up, but
it cannot get master rights, since there can only be 1 master and the
leaked fd is the master. This leads to lots of:
"Couldn't set scan out buffer" errors and plymouth appears frozen
because of this, this is esp. bad with the disk encryption unlock screen
7) When gdm starts, it deactivates plymouth, but does not yet tell it to quit
to avoid flickering. The deactivate makes plymouth drop its master rights,
but this happens on the new broken fd which never got the master rights.
This also makes it impossible for gdm to get master rights, also breaking
gdm, with the following error in the logs:
"(EE) wl_drm@4: error 0: authenicate failed"
Note in theory calling ply_renderer_close() on teardown (from
ply_device_manager_free()) should be fine too, but for some reason
this causes the framebuffer to be all messed up (looks like wrong pitch /
tiling) when this is done after gdm has taken over the framebuffer.
Where as just exiting without calling drmModeRmFB, letting the kernel
clean up behind us, does not trigger this. This feels like it is a kernel
bug bug and I will file a bug for this. But for now we should not call
ply_renderer_close() on teardown to avoid this issue (which would be a
regression).
Hans de Goede [Fri, 6 Sep 2019 15:40:06 +0000 (17:40 +0200)]
plymouthd.defaults: Bump default DeviceTimeout to 8 seconds
The amdgpu driver needs up to 5 seconds to initialize / boot some
AMD GPUs, which makes our 5 second timeout much too close to the actual
needed time, leading to systems where sometimes the boot is fine and the
next boot we fallback to a text based splash because we won the race from
the GPU probe code.
This commit bumps the default DeviceTimeout to 8 seconds giving us a
decent marging here without making it overly long.
Hans de Goede [Sun, 25 Aug 2019 16:01:59 +0000 (18:01 +0200)]
two-step: bgrt: Add workaround for desktops which do not use the golden ratio
On desktops (no panel) we normally do not use the BGRT provided
xoffset and yoffset because the resolution they are intended for
may be differtent then the resolution of the current display.
On some desktops (no panel) the image gets centered not only
horizontally, but also vertically. In this case our default of using
the golden ratio for the vertical position causes the BGRT image
to jump.
To avoid this this commits adds an extra check to see if the provided
xoffset and yoffset perfectly center the image and in that case uses them.
An example of a system needing this workaround is the Minix Neo Z83-4.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 18 Jul 2019 15:51:54 +0000 (17:51 +0200)]
two-step: Deal with buggy firmware which does not pre-rotate the bgrt image
Some buggy Lenovo 2-in-1s with a 90 degree rotated panel, behave as
if the panel is mounted up-right / not rotated at all. These devices
have a buggy efifb size (landscape resolution instead of the actual
portrait resolution of the panel), this gets fixed-up by the kernel.
These buggy devices also do not pre-rotate the bgrt_image nor do
they set the ACPI-6.2 rotation status-bits. We can detect this by
checking that the bgrt_image is perfectly centered horizontally
when we use the panel's height as the width.
This commit uses this check to override the bgrt-rotation read from
the ACPI-6.2 rotation status-bits, fixing us displaying the bgrt image
with the wrong rotation.
ply terminal session: Drop function ply_terminal_session_execute and
ply_terminal_session_open_console, Since this is a feature from a bygone
time which is no longer in use without ply_terminal_session_run.
Hans de Goede [Fri, 24 May 2019 20:49:15 +0000 (22:49 +0200)]
two-step: Add support for firmware-splashes with rotation status bits set
Before the ACPI 6.2 specification, the BGRT table did not contain any rotation
information, so to make sure that the firmware-splash showed the right way up
the firmware would contain a pre-rotated image and our BGRT / firmware-splash
loading code assumed this is alwast true.
Starting with ACPI 6.2 tge bgrt status fields has 2 bits to tell the firmware
the image needs to be rotated before being displayed. If these bits are set
then the firmwares-splash is not pre-rotated and we must handle it differently.
This commit adds support for reading the new rotation bits from the sysfs
bgrt/status file and adds handling for the case where the bits indicate
that the image is not pre-rotated.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 26 May 2019 15:54:05 +0000 (17:54 +0200)]
drm: Fix tiled mode detection
The TILE property is present on all connectors which are DisplayPort
MST (Multi-Stream) outputs, independent if they are connected to a tiled
display are not.
Starting with the 5.2 kernel, it is actually present on almost all outputs.
Rather then just checking if the property is present, check that if it
is present it has a valid (non zero) blob-id assigned to it, this fixes
us mis-identifying DP MST outputs as always being tiled.
Which in turn fixes us failing to pick the preferred mode on these outputs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ZhaoQiang [Tue, 28 May 2019 14:49:41 +0000 (14:49 +0000)]
Translation: Update plymouth.pot's misc infomation
plymouth.pot is using old Bugzilla as issue discussing URL, update it to
Gitlab, and also correct other translation files which already been
traslated.
ZhaoQiang [Thu, 23 May 2019 19:24:55 +0000 (19:24 +0000)]
main.c: Deprecate gdm transition signal
plymouth used to create a file in /var to tell gdm to start in active vt,
but gdm don't use this file now. and create file in filesystem too early
will cause race problem when /var is a seperate partition or it's on an
lvm volume.
Hans de Goede [Mon, 25 Mar 2019 07:13:26 +0000 (08:13 +0100)]
themes: Update spinner and bgrt background settings
Update the spinner and bgrt themes background to solid black so that we get
the same background, independent of whether the firmware-splash (ACPI
BGRT extension) is available and to closer match the mock-ups from:
https://wiki.gnome.org/Design/OS/BootProgress
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 1 Mar 2019 16:22:30 +0000 (17:22 +0100)]
ply-pixel-buffer: Fix right and bottom edge rendering of scaled buffers
When scaling a buffer 2x and calling ply_pixels_interpolate to interpolate
the last row / column, the extra pixels used for pixels would go out of
bounds and be replaced with a black pixel. This causes a 50% dimming of the
last row / column.
This 50% dimming leads to an ugly darkline when a theme draws 2 images
which are supposed to be joined together.
This commit fixes this by clipping the coordinates to the source image
limits instead of using black pixels when interpolating right and bottom
edge pixels.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Feb 2019 10:03:36 +0000 (11:03 +0100)]
Add support for translating the user visible strings in some themes
This commit adds initial translation support, for now translation support
is limited to the user visible strings in some splash plugins and themes,
the daemon and commandline utils output are left untranslated for now.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Feb 2019 09:23:06 +0000 (10:23 +0100)]
Prefix Title and Subtitle theme config keywords with an underscore
Prefix Title and Subtitle theme config keywords with an underscore ('_')
so that "intltool-extract --type=gettext/ini" can be used to make the
title and subtitle translatable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 25 Feb 2019 15:47:13 +0000 (16:47 +0100)]
Add new reboot and system-upgrade modes
Some themes show certain text strings to the user depending on the mode,
see e.g. the shutdown vs reboot mockups of:
https://wiki.gnome.org/Design/OS/BootProgress
Besides during shutdown vs reboot, we also want different theming for
installing offline (security) updates versus doing an offline OS upgrade.
To make this possible this commit adds new reboot and system-upgrade
modes which can be specified either when starting plymouthd, or through
plymouth change-mode --<mode>.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 25 Feb 2019 14:45:26 +0000 (15:45 +0100)]
main: Remove private ply_mode_t
Remove the private ply_mode_t from main.c, this is a 1:1 mirror of
ply_boot_splash_mode_t, so use ply_boot_splash_mode_t directly, leading
to a nice cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 13 Feb 2019 14:10:23 +0000 (15:10 +0100)]
plymouthd.defaults: Change default ShowDelay to 0
ShowDelay was added with as goal to reduce the number of jarring /
flickering visual transitions.
The idea being that if a system boots within 5 seconds, we would avoid
the transition from a black screen to plymouth, instead directly going
to e.g. gdm.
In practive most modern systems (with SSD) take about 4-7 seconds to
boot, this causes plymouth to only show briefly (aprox. 1 second).
IOW on some modern systems it quicky flashes by, this "flash" is the end
result of the ShowDelay=5 default which is intended to *reduce* the number
of jarring / flickering visual transitions.
On older systems the boot will likely take significantly longer then the
5 seconds, so we will show the splash anyways and we might as well show
it right away, so that the user can see something is happening right away.
Note this has been discussed in more detail in issue #64, which also
contains an alternative much more involved fix for the issues surrounding
SplashDelay, but simply defaulting it to 0 seems to be best.
Closes #64
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 16 Jan 2019 11:51:05 +0000 (12:51 +0100)]
ply-boot-splash: Do not add ply_boot_splash_update_progress timeout multiple times
Before this commit when freeing the splash, the following would be logged:
multiple matching timeouts found for removal
multiple matching timeouts found for removal
This is caused by us adding the ply_boot_splash_update_progress timeout
handler to the event loop 3 times: 1 on first show, 2 on second show with
a different mode, 3 on becoming idle.
This commit fixes the 2nd add by stopping the timer when changing modes
and the 3th add by not calling ply_boot_splash_update_progress to update
the progress, as that will re-add itself. Instead this commit directly calls
plugin_interface->on_boot_progress from ply_boot_splash_become_idle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 16 Jan 2019 11:27:01 +0000 (12:27 +0100)]
logging: Minor log-message fixes
This fixes 2 minor issues with our log-messages:
1. ply_trace adds a "\n" itself, so there is no need to pass one extra.
2. Correct spelling of quitting
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 13 Feb 2019 13:39:42 +0000 (14:39 +0100)]
logging: Improve logging format
This commit adds 2 improvemens to the ply_trace logging format:
1) It prefixes the log messages with timestamps (since system boot)
2) Previously function-names where right aligned / left padded to 45
characters. But they were prefixed with a [file:line] prefix which does
not have a fixed width, making the column aligment for the actual messages
fail resulting in hard to read logs.
This commit fixes 2. by printing "<timestamp> file:line:func" to a
prefix-buffer and then left-aligning / right padding this prefix buffer
to 75 chars.
The resulting logged lines now look like this:
00:00:01.741 main.c:1928:check_logging : checking if console messages should be redirected and logged
00:00:01.741 main.c:1937:check_logging : logging will be enabled!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 12 Feb 2019 14:15:26 +0000 (15:15 +0100)]
two-step: Add a per mode setting to suppress messages
The messages passed to plymouth display-message can be quite verbose, esp.
in the offline-updates case. Combined with some themes now showing their
own prominent title message explaining what is going on this leads to
undesirable repetitive text being shown.
This commit adds support for a per mode SuppressMessages setting which
allows themes to suppress messages passed to plymouth display-message
on a per mode basis.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 8 Feb 2019 21:41:15 +0000 (22:41 +0100)]
two-step: Add progress-bar support
Some themes may want to use a progress-bar instead of the throbber for
some modes. This commit adds a new per mode UseProgressBar setting allowing
this.
One case where this will be used is the offline updates splash-screen
mockup from: https://wiki.gnome.org/Design/OS/BootProgress
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 7 Feb 2019 16:44:32 +0000 (17:44 +0100)]
two-step: Add MessageBelowAnimation option
So far we've always printed messages coming from "plymouth display-message"
in the top left corner. In some cases the theme may want to instead display
the messages below the animation (where they are more prominently visible).
My first attempt to support this added MessageHorizontal/VerticalAlignment
options. That did not work since we want a more or less fixed distance
between the animation bottom and the message and with screen-heights varying
from 480 to 1200 that is not possible using alignment options to place both
the animation and the message.
Note the default is unchanged and still is the top left corner.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
projects / thirdparty / plymouth.git / log
