Hans de Goede (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
hansdegoede) wrote2022-11-05 03:53 pm
hansdegoede) wrote2022-11-05 03:53 pm
Results of requested backlight testing for 6.1
I have received quite a few test reports in response to my previous blog post. Many thanks to everyone who has run the tests and send me their results!
These tests show that as a result of the current 6.1 changes quite a few laptop models will end up with an empty "/sys/class/backlight", breaking users ability to control their laptop panel's brightness.
I have submitted a patch-set for 6.1 upstream to fix this.
More detailed summary/analysis of the received test reports:
The fixes for 6.1 restore the behavior where userspace can see multiple entries under "/sys/class/backlight" for a single panel and the kernel leaves figuring out which one actually works up to userspace. This is undesirable and having more then 1 backlight device for a single panel also blocks the new backlight userspace API work which I have planned.
This first round of testing has shown that native works well even on systems so old that they don't have acpi_video backlight control support.
So I have prepared a patch series to try again with 6.2 by making native be preferred over vendor, which should avoid the problems seen with the 6.1 changes before the fixes.
These tests show that as a result of the current 6.1 changes quite a few laptop models will end up with an empty "/sys/class/backlight", breaking users ability to control their laptop panel's brightness.
I have submitted a patch-set for 6.1 upstream to fix this.
More detailed summary/analysis of the received test reports:
- Known Windows laptop models affected by this:
- Acer Aspire 1640
- HP Compaq nc6120
- IBM ThinkPad X40
- System76 Starling Star1
- Known MacBook models affected by this:
- Apple MacBook 2.1
- Apple MacBook 4.1
- Apple MacBook Pro 7.1
- 30 unaffected models
- The Dell Inspiron N4010 has acpi_video support and acpi_osi_is_win8() returns false, so acpi_video_get_backlight_type() returns acpi_video, but acpi_video fails to register a backlight device due to a _BCM eval error. This model already has a DMI quirk for this, so it is unaffected.
- The following laptop models use vendor backlight control method, while also having a native backlight entry under /sys/class/backlight:
- Asus EeePC 901 (native backlight confirmed to work better then vendor)
- Dell Latitude D610 (native backlight confirmed to also work)
- Sony Vaio PCG-FRV3 (native backlight control does not work, BIOS from 2003!)
The fixes for 6.1 restore the behavior where userspace can see multiple entries under "/sys/class/backlight" for a single panel and the kernel leaves figuring out which one actually works up to userspace. This is undesirable and having more then 1 backlight device for a single panel also blocks the new backlight userspace API work which I have planned.
This first round of testing has shown that native works well even on systems so old that they don't have acpi_video backlight control support.
So I have prepared a patch series to try again with 6.2 by making native be preferred over vendor, which should avoid the problems seen with the 6.1 changes before the fixes.