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 Jelle van der Waa (jelly) - Wednesday, 23 November 2022, 11:08 GMT
Opened by Hans de Goede (hansdegoede) - Thursday, 09 December 2021, 18:47 GMT
Last edited by Jelle van der Waa (jelly) - Wednesday, 23 November 2022, 11:08 GMT
|
Details
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: 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
Closed by Jelle van der Waa (jelly)
Wednesday, 23 November 2022, 11:08 GMT
Reason for closing: Implemented
Additional comments about closing: mkinitcpio 33-1
Wednesday, 23 November 2022, 11:08 GMT
Reason for closing: Implemented
Additional comments about closing: mkinitcpio 33-1
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.
From https://lore.kernel.org/intel-gfx/20210421204804.589962-1-hdegoede%40redhat.com/ I understand that those are ACPI & WMI modules inside /drivers/platform/x86/, but looks like there's /drivers/platform/chrome/chromeos_privacy_screen.ko.zst now too.
Best I can think of is grepping for '/drivers/platform/.*(acpi|privacy|wmi)'.
Dracut has the ability to look at which functions/symbols a module depends on and then it uses that to detect drivers which may register a privacy-screen, specifically it checks for modules which depend on the drm_privacy_screen_register symbol. That is what it does for the generic initrd (which should work everywhere) case.
For a host-specific (smaller, optimized) initrd it does:
for i in /sys/class/drm/privacy_screen-*/device/driver/module; do
[[ -L $i ]] || continue
modlink=$(readlink "$i")
modname=$(basename "$modlink")
instmods "$modname"
done
where instmods is the dracut function to add a module (+ its deps) to the initrd.
mkinitcpio doesn't implement anything like that and, AFAIK, nothing like that is planned.
Attached poc.c dereived from dracut-install.c.
gcc poc.c -lkmod
./a.out drm_privacy_screen_register /usr/lib/modules/$(uname -r)/kernel/drivers/platform/{chrome,x86}/*
This is very rough but it outputs the expected modules using drm_privacy_screen_register.
Your poc does work, but I'm unsure if adding a C program to a fully Bash project is the best course of action. This was very limited use cases.
It would also complicate relicensing ( https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/118 ) if we ever decide on that.
For the limited use case adding the modules thinkpad_acpi and chromeos_privacy_screen would be the simplest solution. No new modules are using it in 6.1 and I can not see any commits using it intended for 6.2. This also avoids 32 false positives produced by '/drivers/platform/.*(acpi|privacy|wmi)'.
You could also use grep/zgrep/xzgrep/zstdgrep to do a string search on the module binary or decompress then use nm.
How would licensing be complicated? GPL2+ permits re-licensing to GPL3+.