Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#72964 - [mkinitcpio] 31-1 Add privacy screen modules to the initrd
Attached to Project:
Arch Linux
Opened by Hans de Goede (hansdegoede) - Thursday, 09 December 2021, 18:47 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 11 March 2022, 07:28 GMT
Opened by Hans de Goede (hansdegoede) - Thursday, 09 December 2021, 18:47 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 11 March 2022, 07:28 GMT
|
DetailsStarting with kernel 5.17 the kernel supports the builtin privacy screens built into the LCD panel of some new laptop models.
This means that the drm drivers will now return -EPROBE_DEFER from their probe() method on models with a builtin privacy screen when the privacy screen provider driver has not been loaded yet. To avoid any regressions arch should modify its initrd generation tool to include privacy screen provider drivers in the initrd (at least on systems with a privacy screen), before 5.17 kernels start showing up in the arch repos. If this change is not made, then users using a graphical bootsplash (plymouth) will get an extra boot-delay of up to 8 seconds (DeviceTimeout in plymouthd.defaults) before plymouth will show and when using disk-encryption where the LUKS password is requested from the initrd, the system will fallback to text-mode after these 8 seconds. I've written a patch with the necessary changes for dracut, which might be useful as an example for how to deal with this, see: https://github.com/dracutdevs/dracut/pull/1666 ATM the only kms driver using privacy screens is the i915 driver and the only provider is the thinkpad_acpi driver. But both are likely to change (and change soon!), so the detection really should be made dynamic as has been done in the dracut patch. |
This task depends upon
2. I have a test ThinkPad where I can make some space free for arch and then I can loan it to @jelly for testing for a couple of days.
3. This is not so much about benefits, as it is about keeping things working. Starting with 5.17, if you want to have working drm/kms inside the initrd (for plymouth for example); and your laptop has a supported builtin privacy-screen, then the driver providing the privacy screen MUST be in the initrd for drm/kms to work; and if you are loading modules manually (rather then say using udev) then it MUST be loaded before the drm/kms drivers.
Early kms will NOT work on a device with a supported privacy screen if the initrd does not contain the driver providing the privacy screen class device.
The probe() method of e.g. the i915 driver will fail with -EPROBE_DEFER if it cannot locate the privacy screen provider and as such the i915 driver will not bind to the iGPU, so kms will not work.
The kernel automatically retries probe() calls for drivers where their probe() returned -EPROBE_DEFER, so once the privacy driver is loaded then *and only then* the i915 driver will bind and provide kms functionality.