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
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
