Добавлена переменная конфигурационного файла
FBDeviceTimeout, по истечении которого plymouth будет ожидать не только DRM
устройства, но и framebuffer. По истечении DeviceTimeout plymouth будет
запущен для text mode.
If a device gets added when we're already deactivated, plymouth shouldn't
process the device, since processing it effectively activates plymouth.
This commit pulls the udev monitor fd out of the event loop while
plymouth is deactivated so new events are deferred until reactivation.
Modified by Iain Lane <iain.lane@canonical.com>: Also deactivate the
timer that finds all devices known to udev after an interval, when
paused.
If neither "rhgb" nor "splash" is on the kernel cmdline, then
plymouth forces the "details" splash. This splash is merely
a passthrough plugin, where it makes boot looks like plymouth
isn't even running.
In this case, the code sets PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV.
The idea is to not bother waiting for udev events notifying
plymouth when graphics devices show up, since it doesn't need
to use the grpahics devices directly anyway.
Unfortunately, it does still erroneously try to setup graphical
renderers in this case, including the /dev/fb renderer.
Before commit e4f86e3c, these graphical renderers failed because
they were given the wrong device name, but since that fix, they're
suceeding. We definitely don't want the /dev/fb renderer to
load if we're ignoring udev on efi systems, since during very
early boot /dev/fb is backed by efifb, something we never want to
use. efifb is supposed to get replaced during the boot process
by other fb implementations like say radeondrmfb, virtiodrmfb or
bochsdrmfb, and some of those implementations can't handle the
transition if /dev/fb is open at switchover time.
This commit adds a new flag to tell the device manager to
not bother trying to setup graphical renderers when details are
forced.
http://bugzilla.redhat.com/1518464
https://lists.freedesktop.org/archives/systemd-devel/2015-March/029184.html
As explained there, plymouth watching for coldplug events is not the
behaviour we're looking for.
Replace this with a configurable timeout. We claim DRM devices as soon as
we're aware of them (displaying the splash still subject to ShowDelay),
but legacy framebuffer and text console devices are only claimed after
this new DeviceTimeout.
This avoids an issue where the initramfs finishes (generating a coldplug
event) before udev has informed plymouth of the DRM devices. This was
causing plymouth to activate text mode and ignore the DRM devices appearing
a moment later.
https://bugs.freedesktop.org/show_bug.cgi?id=95356
The seat abstraction isn't really right, since it forces creating a
link between terminal and video output device, which isn't really
necessary (and other reasons).
This commit drops the abstraction, and moves all the code that was
in ply-seat.c directly to ply-device-manager.c.
At the moment, we hardcode /dev/dri/card0 for the DRM device.
This works well enough in the lion's share of cases, but there are cases
where it falls over. Namely, machines with multiple GPUs, such as
optimus hardware, sometimes end up with the kernel fb console going to
/dev/dri/card1.
Rather than trying /dev/dri/card0 then /dev/dri/card1 etc in succession,
this commit, instead, adds support for querying udev for the
information.
There's quite a bit of logic for managing input and output in
main.c right now. That code is already a bit too complicated,
but will get even more complicated going forward if we want
to add udev support, etc.
In an effort to keep things from getting too unwieldly, this
commit breaks out a lot of the logic into a new
ply-device-manager class.
A subsequent commit will make main.c use the new class.
Хирецкий Михаил
Ray Strode
Adam Williamson
Daniel Drake