Created attachment 107084 [details] Proposed blacklist patch This bug is meant to track regressions since v3.7 that caused backlight to stop working on several machines (e.g bug 52951, bug 51231). The simple solution is to blacklist these machines until a proper solution is working correctly, which as of v3.11-rc3, that's not the case. If your machine works correctly with acpi_osi="!Windows 2012", and doesn't otherwise, comment with the name of the laptop, plus the output of this command: % dmesg | grep DMI --- Since v3.7 the acpi backlight driver doesn't work correctly in several machines because ACPI code has different code for Windows 8, and the rest. The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however it introduced several other issues in different machines. This patch fixes both regressions by blacklisting the win8 OSI, so we are back to v3.6 behavior, and it should remain that way until the intel backlight driver is fixed. Since v3.7, users have been forced to fix the initial regression by modifying the boot arguments (acpi_osi="!Windows 2012"). https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A https://bugzilla.kernel.org/show_bug.cgi?id=52951 https://bugzilla.kernel.org/show_bug.cgi?id=51231 TODO: * Toshiba Portege R930 * Lenovo G560a * Asus UX21A
The Dell Inspiron 15R SE is also affected. DMI output: [ 0.000000] DMI: Dell Inc. Inspiron 7520/0PXH02, BIOS A09 11/15/2012
(In reply to Danny Baumann from comment #1) > The Dell Inspiron 15R SE is also affected. DMI output: > > [ 0.000000] DMI: Dell Inc. Inspiron 7520/0PXH02, BIOS A09 11/15/2012 Does intel_backlight work? I mean, if you specify intel_backlight in xorg.conf, is everything working OK?
(In reply to Aaron Lu from comment #2) > Does intel_backlight work? I mean, if you specify intel_backlight in > xorg.conf, is everything working OK? Yes. I much prefer acpi_video though, because the minimum brightness with acpi is not 'off', but a sane usable value. Is this different from the other machines here? I see 'several other issues' being mentioned, but not exactly what those issues are.
(In reply to Danny Baumann from comment #3) > Yes. I much prefer acpi_video though, because the minimum brightness with > acpi is not 'off', but a sane usable value. I think exactly the same. I have a patch to fix the minimum brightness with the intel driver (all the drivers actually), but it needs more work to make it work properly everywhere. > Is this different from the other machines here? I see 'several other issues' > being mentioned, but not exactly what those issues are. The minimum brightness is one issue for me, but I don't think it was reverted because of that. I don't know the details of why it got reverted.
(In reply to Danny Baumann from comment #1) > The Dell Inspiron 15R SE is also affected. DMI output: > > [ 0.000000] DMI: Dell Inc. Inspiron 7520/0PXH02, BIOS A09 11/15/2012 Just to be clear; if you boot with acpi_osi="!Windows 2012", everything is fine, and you don't notice any adverse effects?
(In reply to Felipe Contreras from comment #4) > I think exactly the same. I have a patch to fix the minimum brightness with > the intel driver (all the drivers actually), but it needs more work to make > it work properly everywhere. Are the driver developers in agreement that there actually is something that needs to be fixed? When I tried to do that ([1]), I didn't look like that. Is your patch already available publically? (In reply to Felipe Contreras from comment #5) > Just to be clear; if you boot with acpi_osi="!Windows 2012", everything is > fine, and you don't notice any adverse effects? Yes. You can see [2] for the details. [1] https://lkml.org/lkml/2013/3/26/160 [2] https://bugzilla.kernel.org/show_bug.cgi?id=55071
(In reply to Danny Baumann from comment #6) > (In reply to Felipe Contreras from comment #4) > > I think exactly the same. I have a patch to fix the minimum brightness with > > the intel driver (all the drivers actually), but it needs more work to make > > it work properly everywhere. > > Are the driver developers in agreement that there actually is something that > needs to be fixed? When I tried to do that ([1]), I didn't look like that. > Is your patch already available publically? More or less. It depends on the exact change. The change you proposed was only for i915, and it's hard to push it that way. My change would be for all backlight drivers, and will update the documentation about the interface, so it's clear what we provide to user-space. The developers are not certain that 0 being off is bad, but they seem to agree that consistency is desirable (so if 0 is off, it should be off on all drivers). However, they don't think it's possible to achieve this consistency, but I think my patch can do that. We'll see. > (In reply to Felipe Contreras from comment #5) > > Just to be clear; if you boot with acpi_osi="!Windows 2012", everything is > > fine, and you don't notice any adverse effects? > > Yes. You can see [2] for the details. All right, thanks. I'll add it to the list.
The patch gets reverted because intel_backlight has bugs for some systems.
Hello, you can add the "Lenovo ThinkPad Edge E530" laptop which functions correctly with acpi_osi="!Windows 2012". Alternatively adding 'acpi_osi=Linux acpi_backlight=vendor' to the kernel command line achieves the same result although thinkpad-acpi spams the log with warnings about unhandled HKEY events. dmesg | grep DMI [ 0.000000] DMI: LENOVO 3259A2G/3259A2G, BIOS H0ET92WW (2.52 ) 04/23/2013
Created attachment 107282 [details] acpi: blacklist win8 OSI for buggy laptops v2 Updated patch. The list is now: * ASUS Zenbook Prime UX31A * Dell Inspiron 15R SE * Lenovo ThinkPad Edge E530 The rest need to be confirmed before they get added.
I own a ThinkPad Edge E530, too, but it has a different DMI-String: $ dmesg | grep DMI [ 0.000000] DMI: LENOVO 3259CTO/3259CTO, BIOS H0ET92WW (2.52 ) 04/23/2013 I think we should match either on "DMI_PRODUCT_VERSION" = "3259*" or hope that future bios versions will be fixed and only match on "BIOS H0ET92WW (2.52 )"
This does indeed seem to be fixed with the newer BIOS version (2.54 ), I have [ 0.000000] DMI: LENOVO 3259HJG/3259HJG, BIOS H0ET94WW (2.54 ) 08/02/2013 I also had the problem with earlier versions (not all though, I can't remember when it started).
I can confirm that BIOS 2.54 on Lenovo B530 is fixed! So only Bios 2.52 needs to be blacklisted. So we should match on DMI_MATCH(DMI_BIOS_VERSION, "H0ET94WW (2.54 )")
Sorry, I meant it's fixed on Lenovo E530, not B530! $ dmesg | grep DMI [ 0.000000] DMI: LENOVO 3259CTO/3259CTO, BIOS H0ET94WW (2.54 ) 08/02/2013
Actually, although I cannot prove that now, I'm pretty sure that previous versions had the same error, IIRC the whole 2.5* line had it (i.e. 2.50, 2.51 and 2.52). I guess it won't do too much harm to just blacklist all versions prior to 2.54.
*** Bug 61231 has been marked as a duplicate of this bug. ***
Add to list: Asus Aspire V5-573G, black screen on boot and osi !Windows 2012 fixes it. [ 0.000000] DMI: Acer Aspire V5-573G/Dazzle_HW, BIOS V2.13 06/28/2013
ThinkPad T431s showed same problems as the other ThinkPads detailed in Bug 51231, and "!Windows 2012" fixed it. [ 0.000000] DMI: LENOVO 20AACTO1WW/20AACTO1WW, BIOS GHET22WW (1.07 ) 06/13/2013
Asus Aspire V5-572G is also affected. The specified kernel line fixes the problem, thanks! [ 0.000000] DMI: Acer Aspire V5-572G/Dazzle_CX , BIOS V2.07 07/12/2013 (It also happend with the previous bios v2.01). I tested the following kernels with the black screen problem: 3.8.0-31 3.11.1 3.12-rc1
ThinkPad T430 shows the same problems as the other ThinkPads detailed in bug 51231, and "!Windows 2012" fixed it. T430 with UEFI 2.56 in UEFI-only mode, without CSM: [ 0.000000] DMI: LENOVO 2349D15/2349D15, BIOS G1ET96WW (2.56 ) 07/18/2013
OK, here's the new list. ASUS Zenbook Prime UX31A Dell Inspiron 15R SE ThinkPad Edge E530 (3259CTO, 3259HJG, 3259A2G) Acer Aspire V5-573G Acer Aspire V5-572G ThinkPad T431s ThinkPad T430
Over at #61231 I was asked to un-duplicate this. So scratch entry for Asus Aspire V5-573G (?)
(In reply to erno from comment #22) > Over at #61231 I was asked to un-duplicate this. > So scratch entry for Asus Aspire V5-573G (?) No, the entry should remain. The bug should be fixed in both places, so when the Intel driver is used by default, you don't get any regression.
Anyone still follow this bug? If not, I'll close it.