Arch Linux

Please read this before reporting a bug:

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
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


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

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

Comment by Hans de Goede (hansdegoede) - Thursday, 09 December 2021, 18:48 GMT
Erm, I just realized that the Subject/Summary line is wrong I copy and pasted that from the Fedora bug report (where dracut is used), there is no patch (yet) for Arch's initrd generator, sorry.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 10 December 2021, 12:13 GMT
I haven't looked at module sizes yet, since I haven't used 5.17. Also, I would not be able to test this, since I don't own hardware that supports the privacy screen provider. Third, what are the benefits of early loading this?
Comment by Hans de Goede (hansdegoede) - Friday, 10 December 2021, 12:31 GMT
1. My xz compressed thinkpad_acpi.ko is 43k big and I expect most of its dependencies to already be in a drm/kms using initrd anyways. The 2 likely new dependencies are the rfkill and platform_profile modules which both are tiny.

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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 10 December 2021, 12:37 GMT
Well, plymouth is not used by default on Arch. So, people using it, can use MODULES= to load what they need, in the order they need. Now, if early KMS doesn't work, at all, without the privacy screen modules, then it's another matter entirely. I suspect it will work, but I haven't looked at privacy screen code in the kernel yet.
Comment by Hans de Goede (hansdegoede) - Friday, 10 December 2021, 12:50 GMT
I am the author of the new kernel drm privacy screen code (I filed this bug as a courtesy to avoid regressions in Arch).

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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 10 December 2021, 12:53 GMT
Gotcha, so, early KMS won't work *at all*. Yes, in that case we should include the privacy modules. Perhaps now will be a good time to drop the fallback initramfs.