GitLab

themes: Update spinner and bgrt background settings

See merge request plymouth/plymouth!32

Add new fur and sr translations from fedora.zanata.org :
https://fedora.zanata.org/iteration/view/plymouth/masterSigned-off-by: Hans de Goede <hdegoede@redhat.com>

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/BootProgressSigned-off-by: Hans de Goede <hdegoede@redhat.com>

ply-pixel-buffer: Fix right and bottom edge rendering of scaled buffers

See merge request plymouth/plymouth!31

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>

Theme translation support

See merge request plymouth/plymouth!30

Sync the translations with the translations from zanata:
https://fedora.zanata.org/iteration/view/plymouth/masterSigned-off-by: Hans de Goede <hdegoede@redhat.com>

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>

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>

Add new reboot and system-upgrade modes

See merge request plymouth/plymouth!29

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>

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>

Make ProgressBarShowPercentComplete a per mode setting, this gives the
theme more flexibility wrt which messages to show in different modes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

plymouthd.defaults: Change default ShowDelay to 0

Closes #64

See merge request plymouth/plymouth!26

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>

Misc fixes

See merge request plymouth/plymouth!25

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>

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>

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>

Improved offline updates theme support

See merge request plymouth/plymouth!24

Make the spinner and bgrt offline updates mode match the GNOME design
mockups from: https://wiki.gnome.org/Design/OS/BootProgressSigned-off-by: Hans de Goede <hdegoede@redhat.com>

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>

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/BootProgressSigned-off-by: Hans de Goede <hdegoede@redhat.com>

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>

The idea behind this is to allow a splash-screen containing something like this:

            <TITLE FONT>Installing updates...</TITLE FONT>

                    Do not turn off your computer

                      /-----------------------\
                      |Animation / progres-bar|
                      \-----------------------/

As can be seen in the mockups here:
https://wiki.gnome.org/Design/OS/BootProgressSigned-off-by: Hans de Goede <hdegoede@redhat.com>

We want theme files to be able to specify different settings for
different modes ("boot-up" / "shutdown" / "updates"). Specifically we
want themes to be able to specify a text for (offline) updates mode to
tell the user what is going on, see the mockups at:
https://wiki.gnome.org/Design/OS/BootProgress

This commit adds support for per mode settings to the two-step plugins
and for starters moves the UseFirmwareBackground setting there, since we
don't want to show the firmware-background when showing the help-text.

Follow-up commits will add support for specifying the (optional) per mode
text to show, note eventually we will need to make these texts translatable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This is always set to true if plugin->background_bgrt_image is set, so
we can simply check for plugin->background_bgrt_image instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Before this commit ply_progress_bar_show would take coordinates for where
to show the progress-bar but the width and height were hardcodec. This
commit adds width and height parametes, so that the caller can specify
the width and height too.

This commit does not change behavior for existing users (tested with the
spinfinity theme).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Allow choosing a fore- and back-ground color instead of hardcoding
the foreground to white and the background to transparent.

This commit does not change behavior for existing users (tested with the
spinfinity theme).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

All the other plymouth widgets do a (re)draw when one of their
properties get updated. Make ply-progress-bar also do this, this allows
dropping the draw calls directly after the 2 current callers of
ply_progress_bar_set_percent_done.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Users of ply_label may want to know the height / width of the text before
calling ply_label_show, so that they can e.g. vertically align it.

This commit adds a size_needs_update bool to the label plugin and uses this
to check if executing size_control is necessary before returning the
width / height and also modifies the ply-label code to load the plugin
from its get_width / get_height methods.

As an added advantage this will also skip unnecessary size_control calls
when calling ply_label_show on an already visible label.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

boot-server: fix type confusion when allocating connection object

See merge request plymouth/plymouth!27

Right now we allocate enough room for a whole ply_boot_server_t
object for every connection object.

This commit mops up the over-allocation

Drm hotplug

See merge request plymouth/plymouth!23

Not only handle add but also change events for drm-subsys devices,
change events are generated when the hardware detect a new monitor
has been plugged in.

This is esp. important with modern DisplayPort MST docking stations where
discovery / enumeration can take so long that the connected displays
are not enumerated by the kernel yet when the drm plugin first calls
drmModeGetResources(). Causing the monitors on these docks to sometimes
not show plymouth during boot (based on various timing parameters).

Note that if during the add event drm-renderer could not be bound, this
commit tries to re-bind the DRM renderer on change events in case a
monitor got plugged into a GPU which did not have anything connected before.
This often happens with the second GPU in a laptop with a hybrid GPU setup.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1652279Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Drm devices generate a bunch of add and change events when the kms
driver loads, consume these all in one go.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

When the code to pick the preferred-mode for outputs was first added, it
was limited to UEFI systems, since it was necessary there.

It was not enabled everywhere right away because there were some worries
it might cause regressions.

We've been shipping this for a while now and no regressions have been
reported, moreover with the new hotplug support we really want to pick the
preferred-mode rather then falling back to the first mode in the list.

Therefor this commits removes the check for UEFI systems from
should_use_preferred_mode().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

With Display-Port links, esp. with DP MST links we may need to reset the
mode if the kernel decides to retrain the link.

If the kernel has retrained the link, the list of available modes may
have changed. If it changed and the mode we picked is no longer available
because of this, we treat this as an unplug + replug.

Since we may want to set another mode, the kernel does not automatically
restore the previous mode. So in case the mode did not change we need to
do an explicit mode-set.

This commits adds support for this, by:

1) Adding a scan_out_buffer_needs_reset member to ply_renderer_head
2) Storing the link-status when going over the connector properties
3) Checking the link-status when adding a connector to a head and setting
   the scan_out_buffer_needs_reset flag when the link-status is bad

This commit also makes ply_renderer_head_map set
scan_out_buffer_needs_reset, avoiding an unnecessary round-trip to the
kernel in the first reset_scan_out_buffer_if_needed call.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Now that we can call create_heads_for_active_connectors multiple times
we can implement handle_change_event.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

The drm plugin's map_to_device function will return true if mapping of
any of the heads has succeeded, potentially leaving some heads unmapped.

This causes the "assert (buffer != NULL)" in begin_flush to trigger when
flushing the heads as head->scan_out_buffer_id is 0.

It seems that even though this is a pre-existing problem we sofar have
not hit this, likely because ply_renderer_head_map in pratice never fails.

However with the new monitor hotplug support, a head may be added after
map_to_device is called, triggering the assert.

This commit fixes both the theoretical pre-existing problem and the
actual problem triggered by hotplug support by ensuring that the head
is mapped before flushing it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>