Hi Angel,
On 11/2/22 04:07, Angel Pons wrote:
Hi Hans,
Thank you for warning about the potential regressions that could happen due to the backlight changes in the Linux kernel.
Sorry if this reply sounds a bit scatterbrained, it is very late.
On Tue, Nov 1, 2022 at 7:11 PM Hans de Goede hdegoede@redhat.com wrote:
Just wondering. I'm happy to see coreboot adjusted to make the kernels heuristics work. OTOH though coreboot BIOS users really should not need to upgrade their BIOS to stop things breaking with a new kernel.
I'm not entirely sure what the right balance is.
It is true that firmware updates are risky, and that having to deal with things breaking after an OS update is unpleasant. However, one of the good things about coreboot is that firmware bugs can be fixed (at least most of them). Maximizing compatibility is important, but so is getting firmware bugs fixed. Maybe the right balance is to work around coreboot bugs in the kernel (if necessary) in a way that allows them to be fixed in coreboot, and of course communicate with coreboot (this email is a good example). One of the worst things that could happen is for coreboot to have to work around OSes' workarounds for coreboot because coreboot was broken and the OSes' workarounds are too inflexible for coreboot to start doing the right things: effectively, it would be a deadlock.
That is a good point. So where possible I will try to avoid adding DMI based quirks for coreboot using laptops, because those will hardcode the backlight control-method (to either ACPI video or the "native" GPU register poking method).
Although hardcoding to native should not really be a problem on devices where native actually works, coreboot updates should not impact the native control method there.
Note that I plan to submit a revert for the patch which hides: /sys/class/backlight/intel_backlight when the acpi_video_get_backlight_type() heuristics say that another backlight interface should be used, since it seems that this will break quite a few (mostly older, beginning of Intel x86_64 era) laptops.
Do you have any examples? coreboot supports several older Intel x86_64 platforms, including laptops, that could be affected too.
ATM the list is:
Acer Aspire 1640 Apple macbook-4.1 Dell N1410 IBM ThinkPad X40 System76 Starling Star1 (and I still have a lot of emails / test-reports to process)
These only have a native intel_backlight interface and the heuristics from acpi_video_get_backlight_type() return acpi_backlight_vendor there causing commit b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)") to result in an empty /sys/class/backlight breaking users ability to control there laptop panel's brightness.
I will submit a revert for commit b1d36e73cc1c to avoid these regressing in 6.1 (resulting in some duplicate /sys/class/backlight entries again).
So with the final 6.1 /sys/class/backlight/intel_backlight should stay around, but I do want to try again later since I really want to get rid of the having multiple /sys/class/backlight/ entries for a single panel and then let userspace choose shenanigans.
Agreed. Having multiple backlight entries is confusing, especially when using the same OS install on a bunch of different machines.
I do plan to try to re-introduce that change again later. First I need to change the heuristics to still native on more models so that on models where the native intel_backlight is the only (working) entry they will return native.
I've some ideas on how to change the heuristics which will hopefully fix the beginning of Intel x86_64 era laptops, but I don't think those will help on the coreboot using System76 laptops case...
Well, there's a firmware bug anyway, because brightness controls don't work on Alder Lake when using Windows. And it doesn't look like Windows will accept pull requests anytime soon...
An idea (which may be impractical to implement) would be to not expose intel_backlight if ACPI backlight control is available.
The problematic code path in the heuristics actually is the one where ACPI backlight control is *not* available, arm the heuristics just return "vendor" (e.g. dell-laptop, asus-wmi, etc. backlight devs) there.
I'm starting to think that the heuristics should prefer native (when available which the heuristics know) over vendor. But that might break (really) old laptops which rely on vendor control now, but which happen to also have (non functional) native backlight control.
Regards,
Hans