Hans de Goede [Mon, 21 Jan 2019 14:41:37 +0000 (15:41 +0100)]
drm: Stop limiting preferred-mode picking to UEFI systems
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>
Hans de Goede [Thu, 17 Jan 2019 10:41:46 +0000 (11:41 +0100)]
drm: Reset mode on display-port connected outputs with a bad link-status
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>
Hans de Goede [Wed, 16 Jan 2019 13:50:34 +0000 (14:50 +0100)]
drm: Ensure heads are mapped before flushing them
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>
Hans de Goede [Tue, 15 Jan 2019 09:43:45 +0000 (10:43 +0100)]
drm: Allow calling create_heads_for_active_connectors multiple times
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>
Hans de Goede [Tue, 15 Jan 2019 08:21:05 +0000 (09:21 +0100)]
drm: Limit backend->resources lifetime to within query_device
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>
Hans de Goede [Tue, 15 Jan 2019 07:58:45 +0000 (08:58 +0100)]
drm: Store and keep all the outputs in the backend
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>
Hans de Goede [Tue, 15 Jan 2019 07:31:20 +0000 (08:31 +0100)]
drm: Stop storing a pointer to drmModeConnector in ply_output_t
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>
Hans de Goede [Tue, 15 Jan 2019 06:31:32 +0000 (07:31 +0100)]
drm: Stop keeing a drmModeConnector instance around
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>
Hans de Goede [Mon, 14 Jan 2019 16:36:22 +0000 (17:36 +0100)]
drm: Refactor ply_renderer_head_add_connector and ply_renderer_head_new
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>
Hans de Goede [Wed, 9 Jan 2019 13:52:33 +0000 (14:52 +0100)]
themes: spinner: Add watermark alignment settings
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>
Hans de Goede [Wed, 9 Jan 2019 13:38:26 +0000 (14:38 +0100)]
plymouth-populate-initrd: Don't assume the ImageDir is the theme-dir
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>
Hans de Goede [Wed, 19 Dec 2018 12:33:08 +0000 (13:33 +0100)]
two-step: Make clearing the dialog-background when using the firmware background optional
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>
Hans de Goede [Wed, 19 Dec 2018 12:28:28 +0000 (13:28 +0100)]
two-step: Add support for non center alignment of the (diskcrypt) dialog
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>
Hans de Goede [Thu, 20 Dec 2018 11:47:39 +0000 (12:47 +0100)]
two-step: Rename UseBGRT to UseFirmwareBackground
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>
Hans de Goede [Wed, 9 Jan 2019 10:31:06 +0000 (11:31 +0100)]
libply: Add ply_key_file_get_bool function
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>
Hans de Goede [Wed, 19 Dec 2018 09:45:51 +0000 (10:45 +0100)]
two-step: Use plymouth_strtod
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>
Hans de Goede [Sun, 9 Dec 2018 14:19:08 +0000 (14:19 +0000)]
Merge branch 'plugin-iface' into 'master'
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
Hans de Goede [Tue, 27 Nov 2018 23:53:46 +0000 (00:53 +0100)]
drm: Pick a controller for unconfigured connectors
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>
Hans de Goede [Tue, 27 Nov 2018 22:09:27 +0000 (23:09 +0100)]
drm: Store tiled and rotation in ply_output_t
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>
Hans de Goede [Tue, 27 Nov 2018 18:50:33 +0000 (19:50 +0100)]
drm: Refactor create_heads_for_active_connectors
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>
Hans de Goede [Tue, 13 Nov 2018 08:03:10 +0000 (09:03 +0100)]
two-step: bgrt: Deal with quirky firmwares
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>
Hans de Goede [Wed, 7 Nov 2018 19:27:08 +0000 (20:27 +0100)]
two-step: Speed up background-tile drawing on HiDPI screens
Before this commit background drawing on HiDPI screens is quite slow
and CPU intensive, because we do the interpolating scale, which does
a whole bunch of double-precision float operations for *each* pixel
for every frame we draw.
When using two-step with a background-tile on a Cherry Trail machine with
a HiDPI screen this results in the diskcrypt password entry being visible
laggy, I can type the password much faster then the bullets show up.
This also means we are pegging the CPU during boot, significantly slowing
down the boot.
This commit fixes this by creating the background_buffer at the screen's
device_scale and rotation, only doing the scaling once.
This commit further speeds things up by also doing the solid/gradient fill
of the background + the alpha blend of the tiled background-image once,
creating a solid background which allows us to hit the
ply_pixel_buffer_fill_with_buffer memcpy fast-path and avoids the need to
re-do the solid/gradient fill + alpha-blend each frame we render.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For some themes we want to use the firmware-logo / splash as background,
when the LCD panel of a laptop is mounted non-upright then the image which
we get from the firmware will be pre-rotated to match the LCD panel mount.
Until now our device-rotation support was limited to using rotated
pixel_buffer-s as destination / canvas only.
This commit adds a ply_pixel_buffer_rotate_upright helper to rotate
a nop-upright source buffer upright so that we can use it as source-buffer
to other functions which expect source-buffers to always be upright.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For some themes we want to use the firmware-logo / splash as background,
when the LCD panel of a laptop is mounted non-upright then the image which
we get from the firmware will be pre-rotated to match the LCD panel mount.
This commit adds ply_pixel_buffer_set/get_device_rotation helpers to
help deal with this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 7 Nov 2018 14:49:40 +0000 (15:49 +0100)]
ply-pixel-buffer: Fix fill_with_buffer fastpath when device_scale != 1
After calling ply_pixel_buffer_crop_area_to_clip_area cropped_area.x/y
are in device coordinates. So when calculating the x/y offset in the
source-buffer due to device-clip areas possible making cropped_area.x/y
larger then just the xoffset/yoffset (in the canvas) we must multiply
the original xoffset/yoffset by device_scale before subtracting.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 7 Nov 2018 11:24:12 +0000 (12:24 +0100)]
ply-renderer: Add ply_renderer_get_panel_properties function
For some themes we want to read the firmware-logo to use as background,
when the LCD panel of a laptop is mounted non-upright and/or if it is
using scaling because of HiDPI then the image which we get from the
firmware will be pre-rotated and scaled to match the LCD panel.
This new function will allow renderers to let themes know about this so
that they can adjust for the logo being pre-rotated and scaled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 5 Nov 2018 14:03:28 +0000 (15:03 +0100)]
ply-image: Do not assume all files are PNGs
So far the image loading code has been assuming that all files are PNGs,
this commit makes the code check the file-header before assuming the file
is a PNG.
This is a preparation patch for adding support for also being able to load
BMP files.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 27 Nov 2018 07:24:20 +0000 (08:24 +0100)]
two-step: Fix crash asking for password with multiple heads
Commit 9639ed895331 ("two-step: Fix animation not starting on later
added heads") unconditionally calls view_start_progress_animation() when
adding secondary heads, to fix the animation not running on secondary
heads when not asking for a password.
But we should not start the animation when adding a head after we've
already entered PLY_BOOT_SPLASH_DISPLAY_PASSWORD_ENTRY state, otherwise
we end up starting it a second time when the user is done entering his
password, causing plymouth to crash and the boot to hang.
We already have the is_animating bool to indicate whether animations have
been started or not, use this to decide if we should start the animation
when adding a new head, fixing the crash.
Fixes: 9639ed895331 ("two-step: Fix animation not starting on ... added heads") Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 12 Nov 2018 11:50:33 +0000 (12:50 +0100)]
two-step: Fix animation not starting on later added heads
Fix the animation not starting on heads added after show_splash_screen
has been called. Since the core calls show_splash_screen after adding
the first head / pixel_display in practice this fixes the animation not
starting on all monitors other then the first.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 10 Nov 2018 15:04:31 +0000 (16:04 +0100)]
ply-device-manager: Fix race causing undesired creation of non-gfx devs
On systems with working drm/kms devices we still sometimes see:
"Creating non-graphical devices, since there's no suitable graphics hardware"
in the logs (and actually create non-gfx devices).
This is caused by a race where the create_devices_from_udev timeout handler
runs just after the pivot-root, just at the time when the "udev trigger"
from the real root is done.
This causes create_devices_for_subsystem() to hit the "it's not initialized"
code-path for all drm and fb devices, even though before (from the initrd)
drm-devices where already setup successfully.
One way of solving this would be to stop the timer as soon as we successfully
enumerate the first drm device. But we need the timer to enumerate fb devices
so on machines where some outputs only have a fbdev driver (corner case) this
would break support for those outputs.
Instead this commit moves the found_drm_device and found_fb_device to the
global manager state and sets them from create_devices_for_udev_device().
This way they will be set when we check them from the create_devices_from_udev
timeout handler even if create_devices_for_subsystem skips over the devices
because of the udev trigger race.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 17 Jul 2018 07:46:12 +0000 (09:46 +0200)]
logger: Add a separator between different boot logs
Since we concatenate boot logs one after the other in /var/log/boot.log
it is hard to tell where the logs from one boot end the next boot starts.
This commit makes plymouth write out a separator including a time + date
of the date, when the log file gets opened to add new boot messages to it.
Note ply_logger_open_file() is only called from ply_terminal_session_open_log()
which in turn is only used for /var/log/boot.log, so this only effects
/var/log/boot.log.
Closes #29
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 09:44:28 +0000 (11:44 +0200)]
drm: Use preferred mode for outputs instead of current mode
When enumerating outputs pick the preferred mode instead of the current
active mode, which may be e.g. a very low res mode.
Sofar we've been relying on fbcon setting up the modes for us, but as
mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=101520#c22
we really should not rely on this.
With the recent flickerfree boot changes we can no longer rely on fbcon
to do the setup for us, hence this commit. For now this commit only
changes the mode-picking logic on UEFI setups as we only have
flickerfree boot there. Once the setup code is more mature we should
probably always use it.
Closes #68
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 12:13:19 +0000 (14:13 +0200)]
drm: Refactor ply_renderer_connector_get_rotation
ply_renderer_connector_get_rotation walks over all properties to add
support for selecting the preferred mode we also want to know if a connector
is part of a tiled output or not, which also requires walking over the props.
This commit refactors ply_renderer_connector_get_rotation into
ply_renderer_connector_get_rotation_and_tiled to prepare for this.
While at also properly use ply_pixel_buffer_rotation_t for the orientation
instead of an int.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 08:26:28 +0000 (10:26 +0200)]
drm: Reset LUT/gamma table before the first drmModeSetCrtc call
When we takeover the kms master from whatever process came before us the
LUT table may be a mess making the graphics funky. So lets reset it once
before our first drmModeSetCrtc call.
Closes #59
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Michal Srb [Tue, 23 Oct 2018 07:10:25 +0000 (09:10 +0200)]
throbber: Don't skip last frame when waiting for end.
If the stop_trigger is set and we are waiting for the last frame to stop the
animation, make sure we don't accidentally skip the last frame. It could
happen if the machine is busy and can't keep up with the frames or when the
animation has more than 60 frames (30FPS * 2 seconds).
When running in a container with plymouth installed, plymouth is started
unnecessarily and systemd prints warnings:
[ OK ] Reached target Shutdown.
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Process 253 (plymouthd) has been been marked to be excluded from killing. It is running from the root file system, and thus likely to block re-mounting of the root file system to read-only. Please consider moving it into an initrd file system instead.
It makes little sense to start plymouth in contains, so add
'ConditionVirtualization=!container' everywhere where
ConditionKernelCommandLine=!plymouth.enable=0 appears to disable plymouth
in containers.
Hans de Goede [Mon, 2 Jul 2018 08:01:05 +0000 (10:01 +0200)]
configure: Pass -Wno-cast-function-type if available
plymouth uses function type casts for callbacks in quite a few places, fixing
these needlessly complicates the code, so lets pass -Wno-cast-function-type.
This fixes 218 warnings like this one:
ply-command-parser.c: In function ‘ply_command_parser_stop_parsing_arguments’:
ply-command-parser.c:680:48: warning: cast between incompatible function types from ‘void (*)(ply_command_parser_t *)’ {aka ‘void (*)(struct _ply_command_parser *)’} to ‘void (*)(void *, int, ply_event_loop_t *)’ {aka ‘void (*)(void *, int, struct _ply_event_loop *)’} [-Wcast-function-type]
(ply_event_loop_exit_handler_t)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Jun 2018 07:15:25 +0000 (09:15 +0200)]
main: Fix getting detailed logs from systemd
This are 3 issues with the detailed logs handling:
1) plymouth attaches to the session directly on a show-splash command
(in on_show_splash()), but it does not tell systemd to start printing
details until the splash is actually shown after the splash_delay.
2) If the splash is actually shown during the initrd (e.g. a diskcript
password is necessary) then we tell the initrd systemd instance to
print details, but we don't tell the regular initrd instance which takes
over as pid 1 after the switch-root to print details.
This leads to rather inconsistent logging/printing behavior, e.g.:
* If a diskcrypt password is asked for, we only log details from
the initrd phase.
* If the boot is shorter then splash_delay no details are logged
* If the user presses ESC during boot during the initrd, only initrd
messages are printed
* If the user presses ESC during boot after the initrd, only normal
messages are printed
This commit fixes both these issues by:
1) Telling systemd to print details as soon as we have attached to the session;
and to stop printing details when we detach from the session (*)
2) Telling systemd to print details after the rootfs has been remounted rw
*) This is necessary to have a smooth transition to e.g. gdm if the splash
has not shown because the boot is shorter then splash_delay
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 3 Jul 2018 06:44:33 +0000 (08:44 +0200)]
main: Show details when ESC is pressed during splash_delay
Start listening for keypresses on the first show_splash() call, so that
pressing ESC while we're delaying show the non-details splash will show
the details splash.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 2 Jul 2018 21:46:59 +0000 (23:46 +0200)]
drm: Remove unnecessary reset_scan_out_buffer_if_needed() call from ply_renderer_head_map()
ply_renderer_head_map() gets only called from map_to_device() which
calls activate() directly afterwards which calls
ply_renderer_head_set_scan_out_buffer(), so there is no need for the
reset_scan_out_buffer_if_needed() call.
Not only is it not needed, but it is actually harmful, there are 2 problems
woth it:
1) Normally the drm plugin gets instantiated by ply-renderer.c with
rendered->is_active=true, backend->is_active=false. The
rendered->is_active=true causes the first ply_renderer_activate call
to be a no-op without calling backend->activate(). So when the first
map_to_device() calls happen activate() has not been called yet and we've
not yet claimed master rights, so ply_renderer_head_set_scan_out_buffer()
calls will always fail, resulting in this in a ply-trace:
Mapping buffer for 1920x1080 renderer head
Redrawing 1920x1080 renderer head
Setting scan out buffer of 1920x1080 head to our buffer
Couldn't set scan out buffer for head with controller id 41
This is harmless, but also shows that the reset_scan_out_buffer_if_needed()
is really not needed.
2. If deactivate_renderer() gets called before the first show-splash then
rendered->is_active will become false, so renderer_activate() done before
map_to_device() will now actually call backend->activate() claiming
drm master rights and setting backend->is_active=true.
The map_to_device() -> ply_renderer_head_map() call done after this, calls
ply_renderer_head_redraw() -> flush_head() which under 1. was a no-op
as it exits directly when backend->is_active=false. But now it actually
flushes the buffers by calling reset_scan_out_buffer_if_needed(). This
itself is fine.
But since reset_scan_out_buffer_if_needed() has already happened in
ply_renderer_head_redraw() the reset_scan_out_buffer_if_needed() call this
commit removes would always return false (no reset necessary) causing
ply_renderer_head_map() to destroy the buffer and return an error.
This results in the splash briefly showing, followed by the core soon after
trying another map_to_device(), which again briefly shows the splash, etc.
With the end result being a badly flickering display.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 2 Jul 2018 07:39:12 +0000 (09:39 +0200)]
main: Only activate renderers if the splash uses pixel-displays
Since commit eb147e52b123 ("renderer: support reactivating renderer without
closing it first"), the show_theme() call done by
toggle_between_splash_and_details() will reactivate the renderers after
switching to details mode, causing the drm renderer to switch the screen
from text to graphics mode hiding the details being logged on the console.
This commit fixes this by only calling ply_device_manager_activate_renderers()
and ply_device_manager_deactivate_renderers if the splash uses pixel-displays.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107047
Hans de Goede [Mon, 25 Jun 2018 14:55:39 +0000 (16:55 +0200)]
main: move ply_device_manager_deactivate_renderers() into hide_splash()
hide_splash() should be the counter-part of show_splash(). show_splash()
calls ply_device_manager_activate_renderers() (through show_theme()).
2 of the 3 callers of hide_splash() are already calling
ply_device_manager_deactivate_renderers() directly before calling
hide_splash(). This commit moves the deactivate call into hide_splash()
so that it also gets called from the 3th code-path, which is when
the user hits the escape to key to toggle from the splash to details.
It's important that plymouth deactivates its renderers before going
to details, because those renderers can block the kernel from
initializing fbcon, which the kernel will start doing lazily in the
future:
https://lkml.org/lkml/2018/6/26/489.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107047
projects / thirdparty / plymouth.git / log
