Ray Strode [Wed, 1 May 2024 12:23:00 +0000 (08:23 -0400)]
main: Go back to text mode when quitting (if appropriate)
Since commit 48881ba2ef3d25fd27fd150d4d5957d4df9868e0 plymouth
goes into GRAPHICS mode early on. Unfortunately, there are cases
where it neglects to go back to TEXT mode when quitting. That can
happen if boot finishes before the splash screen is created.
nerdopolis [Fri, 2 Aug 2024 11:56:28 +0000 (07:56 -0400)]
ply-device-manager: Don't log an error when /sys/class/tty/console/active is empty
This is possible on some kernels that were built with CONFIG_NULL_TTY enabled, and were booted with console=ttynull
/sys/class/tty/console/active is empty in this case, so the file being empty is not always an error worth logging
Hans de Goede [Wed, 5 Jun 2024 20:07:32 +0000 (22:07 +0200)]
ply-device-manager: Make create_devices_for_subsystem () return void
Make create_devices_for_subsystem () return void. Its callers do not care
about the return value and currently the return value is not always correct
since if a device is found, found may later become false again if
a subsequent create_devices_for_udev_device () call fails.
Hans de Goede [Tue, 4 Jun 2024 21:07:19 +0000 (23:07 +0200)]
ply-device-manager: Create renderer for simpledrm devices right away
Often when plymouth starts and enumerates udev devices which are already
present at start (coldplug detection), udev is still initializing all
the devices and it reports 0 for udev_device_get_is_initialized ().
It may take a long time for the state of the simpledrm udev device
to change to initialized and for a udev add event to be send.
Especially when the amdgpu kernel module is involved which is very
large for a kernel module and can take op to 7 seconds to load.
In this case it is even possible for plymouth's default DeviceTimeout
of 8 seconds to trigger before the simpledrm device is considered
initialized. See for example these lines extracted from the plymouth-debug
log attached to: https://bugzilla.redhat.com/show_bug.cgi?id=2183743
00:00:02.909 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:01.0/simple-framebuffer.0/drm/card0
00:00:02.910 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized
00:00:10.917 ../src/libply-splash-core/ply-device-manager.c:1237:create_dev: Timeout elapsed, looking for devices from udev
00:00:10.918 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:01.0/simple-framebuffer.0/drm/card0
00:00:10.918 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized
This leads to plymouth falling back to the text splash even when
plymouth.use-simpledrm is passed on the kernel commandline.
Add a special case for simpledrm devices and add these during coldboot
even if they are not initialized yet.
Hans de Goede [Wed, 5 Jun 2024 19:52:19 +0000 (21:52 +0200)]
ply-device-manager: Remove simpledrm renderers before adding normal drm renderers
udev remove events for simpledrm udev devices may arrive after the udev add
event for a normal drm udev device which is replacing the simpledrm device.
When the local_console is managed by a simpledrm renderer and the remove
event for the simpledrm renderer is received after the add event of
the normal drm device, the local_console is left unmanaged breaking legacy
input support.
When this scenario gets hit it breaks entering disk unlock passwords.
Add code to remove simpledrm renderers before adding normal drm renderers
to avoid this.
Hans de Goede [Wed, 5 Jun 2024 19:38:43 +0000 (21:38 +0200)]
ply-device-manager: Move local_console_terminal handling for DRM/FB renderers
create_devices_for_terminal_and_renderer_type () only ever gets called with
a NULL terminal parameter when create_devices_for_udev_device () is calling
it to create a DRM or FB renderer.
Move the use of local_console_terminal as terminal for the first DRM / FB
renderer created from create_devices_for_udev_device () to
create_devices_for_terminal_and_renderer_type () with an extra !terminal
check.
This is a preparation patch for fixing an issue where the local_console
is managed by a simpledrm renderer and the remove event for that gets
processed after the add event of the normal drm device which leaves
the local_console unmanaged breaking legacy input support.
Hans de Goede [Tue, 4 Jun 2024 19:24:22 +0000 (21:24 +0200)]
ply-renderer: Add new PLY_RENDERER_TYPE_SIMPLEDRM renderer-type
Add a new PLY_RENDERER_TYPE_SIMPLEDRM renderer-type to help differentiate
the simpledrm case from the regular drm device case.
simpledrm devices require some special handling in the device-manager,
this is a preparation patch for improving the simpledrm handling
in ply-device-manager.
Add a helper to determine if a udev syspath is a simpledrm device.
This is a preparation patch to for making simpledrm devices their
own renderer-type.
Hans de Goede [Tue, 7 May 2024 10:42:10 +0000 (12:42 +0200)]
ply-device-manager: Revert "Fall back to text plugin if no renderers installed"
The drm renderer may fail to open /dev/dri/card# with -ENOENT when trying
to open/probe a simpledrm registered drm device and the open races with
that drm device being removed to be replaced by a new drm device registered
by the native GPU driver (e.g. i915 / amdgpu).
Switching to text mode immediately when this race gets hit is undesirable,
as it causes text mode on systems where plymouth would run in graphics
mode before. Remove the immediate switch to text mode on -ENOENT.
Delaying the switch to textmode until the timeout as before.
emperor06 [Tue, 4 Jun 2024 14:42:11 +0000 (16:42 +0200)]
ply-utils: Ensure random ints are big enough
Using Math.Random() in a theme script practically always returns zero.
This is because ply_get_random_number uses mrand48 which, while
returning a 64-bit long, restricts the range of its return value
to be no more than 32-bit, and so gets improperly normalized.
This commit addresses the problem by calling mrand48() twice, once for
each 32-bits of the returned value.
Daniel van Vugt [Tue, 27 Feb 2024 06:47:59 +0000 (14:47 +0800)]
ply-utils: Match mutter's default device scale choice
Until now, laptops with a DPI between 192 and 202 would be given a
default scale of 2 by Plymouth, and 1 by Mutter for the login screen.
That made the visual transition a bit ugly so let's match Mutter's
default scale selection. This means the threshold for laptops is now
1.5 x 135 = 202 DPI instead of 192 DPI. And for desktop monitors it's
now 1.5 x 110 = 165 DPI instead of 192 DPI.
label-freetype: fix fallback not working when fc-match isn't available
The new font loading functions introduced in 544e62ac41a490f04d8e6b4e85f8b9fa1171b0cc assume that popen() returns
NULL when fc-match is unavailable or fails. This is incorrect, since
popen() will always start a shell to run the passed command and return a
stream to that shell's stdin and stdout.
This results in an non-null but empty font name being passed to
FT_New_Face(), which fails.
This commit fixes this by also using the fallback font when the font
path read from the popen() stream is empty.
Ray Strode [Wed, 3 Jan 2024 20:37:08 +0000 (15:37 -0500)]
label-freetype: Rework font loading
There's currently this function, set_font_with_fallback, that
almost always gets called with a NULL first argument in the
initramfs, forcing the _with_fallback part of the function to
run.
It's a little strange to have a function with a chunk of code that
hardly ever runs. Furthermore there's a bug where the error variable
is left uninitialized in this case leading to the freetype plugin
sporadically failing to load the fallback font.
This commit reworks things to drop set_font_with_fallback, and just
call FT_New_Face directly in the caller. Fallbacks are handled
at the point where the font path is determined
(previously called query_fc_match, now called find_default_font_path.
Ray Strode [Tue, 2 Jan 2024 22:04:26 +0000 (17:04 -0500)]
label-pango: Try to fix up remove_hexboxes_from_pango_layout
There are a few issues with the remove_hexboxes_from_pango_layout
function, where it's getting offsets wrong and things like that.
This commit changes the approach entirely. Rather than modifying
the text to remove characters without font converage, it just
changes out the glyphs for those characters to be white boxes.
Ray Strode [Tue, 2 Jan 2024 03:04:21 +0000 (22:04 -0500)]
ply-terminal: Only set keyboard mode when changing it
Setting the console keyboard mode is not entirely idempotent.
The kernel may flush the input buffer leading to lost
key strokes. We currently set the mode explicitly on graphics
updates as part of our more general "fix things up in case
something during boot screws with the terminal settings" code.
That leads to keystrokes getting eaten.
This commit makes the terminal more careful about setting the
keyboard mode. It now only changes it when plymouth thinks its
necessary to do so.
In the future we could query the keyboard mode and reset it
when it's wrong, but I think we should hold off on doing that
until shown we need to.
projects / thirdparty / plymouth.git / log
