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.
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.
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.
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.
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.
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.
This reverts commit 03842d5201.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2270030
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.
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/256
Currently translated at 57.1% (4 of 7 strings)
Added translation using Weblate (Kabyle)
Co-authored-by: ButterflyOfFire <butterflyoffire@protonmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/plymouth/master/kab/
Translation: plymouth/main
We currently get warnings during the build like
```
../src/libply/ply-buffer.h:60:20: warning: value computed is not
used [-Wunused-value]
60 | !_ran && (*bytes = (char *) ply_buffer_get_bytes(buffer),
| ^~
```
This commit changes the macro to use a GCC statement expression with
an if statement to work around the warning.
Closes: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/246
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.
Closes: https://bugs.launchpad.net/bugs/2054769
