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=1652279
Signed-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>
To support hotplugging monitors while plymouth is running, we must
rebuild our outputs list and create and/or remove heads as necessary
on every change event.
This commit adds support for removing single outputs (rather then
tearing down the whole backend) and adds a new first step to
create_heads_for_active_connectors which goes over our view of the
outputs before the change and removes any changed outputs from the
heads they belong to, destroying the head if the last output/connector
is removed.
On the first call backend->output_len is 0, so this new first step
is a no-op.
On subsequent calls we can simply build the list as we do on the first
call, changed outputs will already be removed by the new first step
and for unchanged outputs we end up in ply_renderer_head_add_connector
which will ignore the already added connector.
Note this drops the "couldn't connect monitor to existing head" message,
this is confusing when create_heads_for_active_connectors is called more
then once and is unnecessary as ply_renderer_head_add_connector already
logs a message on both failure exit paths.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Allow calling ply_renderer_head_add_connector with an existing
connector_id and ignore this call.
This allows calling create_heads_for_active_connectors multiple times,
only creating/adding heads for new connectors.
This is a preparation patch for adding support for hotplugging
monitors while plymouth is running.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We do not need / use backend->resources anywhere outside of the query_device
function and with the upcoming hotplug support we need to get a fresh set
of resources on change events, so limit the resources lifetime to
query_device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Put all outputs in the outputs array instead of just the connected ones
and store the outputs array and the controller_id-to-head hashtable in the
backend object instead of temporarily allocating them during enumeration.
Also add new heads to the heads list and to the controller_id-to-head
hashtable in ply_renderer_head_new where this really belongs. This
allows nicely balancing these 2 with removing the head from the list
and hash_table in the ply_renderer_head_remove function which is added
in a follow-up commit.
This is a preparation patch for adding support for hotplugging
monitors while plymouth is running.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a new get_output_info helper function, which fill a ply_output_t with
all info related to the connecter based on a connector-id.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for hotplug support, for hotplug support we
want to keep the ply_output_t for connectors around, this change decouples
the lifetime of the drmModeConnector from the ply_output_t lifetime.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this commit we were storing a pointer to the drmModeConnector
in struct _ply_renderer_head, solely so that we can free it when
destroying the head. This was necessary because we also stored a pointer
to the mode we picked, which comes from insided the drmModeConnector.
The drmModeModeInfo struct has no pointers, so we can simply store a copy
of it instead of a pointer, which removes the need to keep the
drmModeConnector around after probing the connectors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Both these function take a bunch of info coming from the ply_output_t
struct and with upcoming changes they are going to be using even more
ply_output_t fields. Instead of passing all these fields one by one,
simply directly pass a pointer to ply_output_t.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This function can be called to notify the renderer of udev change-events.
This is a preparation patch for adding support for hotplugging
monitors while plymouth is running.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a new ply_array_contains_uint32_element which checks if the queried
ply-array contains an element with the passed in uint32_t value.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Update the spinner and bgrt themses diskcrypt dialog to match the dialog
from the "Disk decrypt" mockup from:
https://wiki.gnome.org/Design/OS/BootProgress
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add watermark alignment settings, so that distros can simply drop
a watermark.png into the theme dir from another package and then have it
show up in the right place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The bgrt theme is using the exact same images as the spinner theme,
remove these and point ImageDir to the spinner theme dir instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this commit plymouth-populate-initrd was only recursively copying the
/usr/share/plymouth/themes/$PLYMOUTH_THEME_NAME to the initrd, assuming
that ImageDir will point there.
This makes it impossible for 2 themes to share their ImageDir, which is
desirable for example for the spinner and bgrt themes, which use the same
images with slightly different settings.
This commit also makes plymouth-populate-initrd also copy the ImageDir
if it is different from the theme-dir, making it possible for ImageDir
to point to a different dir.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Since the ask-for-password or ask-question dialog and the firmware background
may intersect so far we've been clearing the screen to black when showing a
dialog and using the firmware background.
This is not always desirable, this commit adds a new
"DialogClearsFirmwareBackground" option to the two-step based theme config
file, which enables this behavior when set.
The new default is to keep using the initial (firmware) background when
showing a dialog, which matches the non firmware-background paths.
Also update the bgrt theme to use the "DialogClearsFirmwareBackground"
option, keeping the current behavior for that theme.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add DialogHorizontalAlignment and DialogVerticalAlignment options which
allow placing the (diskcrypt) dialog aligned at another place then the
center of the screen.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Rename the UseBGRT theme configfile option to UseFirmwareBackground,
to make it clear what this does using language which most users will be
able to understand, rather then using the cryptic BGRT ACPI table reference.
While at it also switch to using the new ply_key_file_get_bool function, so
that users can edit an existing configfile with "UseFirmwareBackground=true"
in there and change it to "=false" and actually have that work as expected.
The switch to ply_key_file_get_bool also fixes a memleak as
ply_key_file_get_value returns a strdup-ed value which we were not free-ing.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a function to read a boolean value from a ply-key-file.
This function will return true if the key exists and it has a value of "1",
"y", "yes" or "true" (case-insensitive). In all other cases it returns
false.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Use the locale agnostic plymouth_strtod helper which always uses a "."
as decimal seperator. This fixes the various Alignment options not working
with some locales.
While at it also add a ply_trace to log the size and chosen centering for
the watermark image.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a ply_strtod helper which always uses "." as decimal separator
independent of the locale.
Using this fixes e.g. HorizontalAlignment in the two-step plugin
not working with some locales.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fix: "warning: enumeration value ‘PLY_KEYBOARD_PROVIDER_TYPE_TERMINAL’
not handled in switch [-Wswitch-enum]" compiler warning.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a renderer goes away on a udev remove event, free keyboards associated with the renderer, before freeing the renderer. This avoids a null pointer dereference when ply_device_manager_deactivate_keyboards gets called later on:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1794292
See merge request plymouth/plymouth!10
So far we've been relying on the kernel fbcon code to set up all outputs,
now that distros have started using deferred fbcon takeover for flickerfree
booting, we can no longer rely on this and in some cases we must pick
our own controllers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This avoids the need to call ply_renderer_connector_get_rotation_and_tiled
twice and thus also the need to call drmModeGetProperty twice for all
properties.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Refactor create_heads_for_active_connectors to prepare it for adding a
step where we assign controllers to connected outputs which do not have
a controller assigned yet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The only way we use mode_index is to get the mode, so its easier to
directly store the mode when we create a head.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Upside-down LCD panels are fixed up in HW by the GOP, so the bgrt image is
not rotated in this case and we should not rotate it to compensate.
While at it also fixup the wrong indentation of the
ply_pixel_buffer_set_device_scale() call.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for using the firmware splash as background for the two-step splash plugin using the ACPI BGRT extension
See merge request plymouth/plymouth!14
Add a new BGRT theme, this is a copy of the spinner theme, using the ACPI
BGRT graphics (firmware boot splash) as logo when available.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On laptops / tablets the LCD panel is typically brought up in
its native resolution, so we can trust the x- and y-offset values
provided by the firmware to be correct for a screen with the panels
resolution.
Moreover some laptop / tablet firmwares to do all kind of hacks wrt
the y-offset. This happens especially on devices where the panel is
mounted 90 degrees rotated, but also on other devices.
So on devices with an internal LCD panel, we prefer to use the firmware
provided offsets, to make sure we match its quirky behavior.
We check that the x-offset matches what we expect for the panel's
native resolution to make sure that the values are indeed for the
panel's native resolution and then we correct for any difference
between the (external) screen's and the panel's resolution.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support to (optionally) use the firmware splash screen logo
from the ACPI BGRT extension as background.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
