Bug 84221

Summary: Failure to recognize ATI backlight when off A/C power/using battery power
Product: ACPI Reporter: brent s. (brent.saner)
Component: Power-VideoAssignee: Aaron Lu (aaron.lu)
Status: CLOSED DUPLICATE    
Severity: normal CC: brent.saner, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.16 Subsystem:
Regression: No Bisected commit-id:
Bug Depends on: 85171, 86431    
Bug Blocks:    
Attachments: lspci and acpidump output from non-working (>3.15-rc8) kernel
lspci and acpidump output from working (3.15-rc8) kernel
dmidecode output
Disable native backlight for SAMSUNG 870Z5E-880Z5E-680Z5E
Kernel output, 3.17
output of acpidump

Description brent s. 2014-09-10 01:42:20 UTC
In versions prior to 3.16.0, ACPI was detected properly for intel_backlight and acpi_video0/acpi_video1.

However, afterwards only intel_backlight is shown via sysfs.
This leads to full brightness (and unable to be altered) when this laptop is plugged into A/C power, and when on battery power a completely disabled backlight (leading to a VERY dim display) and backlight levels unable to be altered.

lspci output:

[bts@workhorse ~]$ lspci | egrep -i 'vga|display'
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] (rev ff)

I've taken the liberty of bisecting, and have discovered the troublesome behavior started with commit 751109aad5834375ca9ed0dcfcd85a00cbf872b:


751109aad5834375ca9ed0dcfcd85a00cbf872b5 is the first bad commit
commit 751109aad5834375ca9ed0dcfcd85a00cbf872b5
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu Jun 5 22:47:35 2014 +0200

ACPI / video: Change the default for video.use_native_backlight to 1

Now that we're hoping to have resolved all of the problems with
video.use_native_backlight=1, make that the default at last.

Link: http://marc.info/?l=linux-acpi&m=139716088401106&w=2
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

:040000 040000 d8f9ae057c052cd94f1adcfc0b298db2c728a315 933b38080034b141fc0c31f54f38f5b232f69c17 M drivers


Bisect log:

[bts@workhorse linux-git]$ git bisect log
git bisect start
# bad: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16
git bisect bad 19583ca584d6f574384e17fe7613dfaeadcdc4a6
# good: [fad01e866afdbe01a1f3ec06a39c3a8b9e197014] Linux 3.15-rc8
git bisect good fad01e866afdbe01a1f3ec06a39c3a8b9e197014
# good: [7b215de3d0abbc4f6daf2efd19e8809af0564490] Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux into next
git bisect good 7b215de3d0abbc4f6daf2efd19e8809af0564490
# bad: [0430e49b6e7c6b5e076be8fefdee089958c9adad] ima: introduce ima_kernel_read()
git bisect bad 0430e49b6e7c6b5e076be8fefdee089958c9adad
# good: [2937f5efa5754754daf46de745f67350f7f06ec2] Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86
git bisect good 2937f5efa5754754daf46de745f67350f7f06ec2
# good: [bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b] Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
git bisect good bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b
# good: [412dd3a6daf0cadce1b2d6a34fa3713f40255579] Merge tag 'xfs-for-linus-3.16-rc1' of git://oss.sgi.com/xfs/xfs
git bisect good 412dd3a6daf0cadce1b2d6a34fa3713f40255579
# good: [c31c24b8251fd44962a9b0bf82c770653bf07f6e] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
git bisect good c31c24b8251fd44962a9b0bf82c770653bf07f6e
# good: [16b9057804c02e2d351e9c8f606e909b43cbd9e7] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 16b9057804c02e2d351e9c8f606e909b43cbd9e7
# bad: [19c1940feab777bb037c665a09f495d08a6c4e6c] Merge tag 'pm+acpi-3.16-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 19c1940feab777bb037c665a09f495d08a6c4e6c
# good: [af76004cf8b4f368583bda22d7e348e40a338b91] Merge tag 'backlight-for-linus-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
git bisect good af76004cf8b4f368583bda22d7e348e40a338b91
# bad: [589e18a973bd6bb8abd2c6d4d8a1dcf5ae1dff61] Merge branch 'pm-cpufreq'
git bisect bad 589e18a973bd6bb8abd2c6d4d8a1dcf5ae1dff61
# good: [830bcac4e483d347087ed51eed564d1467e1e363] cpufreq: intel_pstate: Remove duplicate CPU ID check
git bisect good 830bcac4e483d347087ed51eed564d1467e1e363
# good: [9d674f2107b7dc801db9780f5f6b645f4905372f] Merge branch 'acpi-hotplug'
git bisect good 9d674f2107b7dc801db9780f5f6b645f4905372f
# bad: [de815a6d00da0f8a59e8aebf8efe12e289552a8f] Merge branches 'acpi-general' and 'acpi-video'
git bisect bad de815a6d00da0f8a59e8aebf8efe12e289552a8f
# good: [a4714a898e85205e1118ec923cde43d88eb105f6] ACPI: Fix bug when ACPI reset register is implemented in system memory
git bisect good a4714a898e85205e1118ec923cde43d88eb105f6
# bad: [751109aad5834375ca9ed0dcfcd85a00cbf872b5] ACPI / video: Change the default for video.use_native_backlight to 1
git bisect bad 751109aad5834375ca9ed0dcfcd85a00cbf872b5
# first bad commit: [751109aad5834375ca9ed0dcfcd85a00cbf872b5] ACPI / video: Change the default for video.use_native_backlight to 1

Please let me know if there is any further information I can provide.
Comment 1 brent s. 2014-09-10 01:43:27 UTC
(originally reported downstream at https://bugs.archlinux.org/task/41580 )
Comment 2 brent s. 2014-09-12 02:02:00 UTC
This also exists for 3.16-rc2 as well (note that the 3.17 kernel does not seem to work at all when I try; I seem to be incurring udev issues with that series but my guess is it's still present).
Comment 3 Aaron Lu 2014-09-15 08:56:15 UTC
(In reply to brent s. from comment #0)
> In versions prior to 3.16.0, ACPI was detected properly for intel_backlight
> and acpi_video0/acpi_video1.
> 
> However, afterwards only intel_backlight is shown via sysfs.
> This leads to full brightness (and unable to be altered) when this laptop is
> plugged into A/C power, and when on battery power a completely disabled
> backlight (leading to a VERY dim display) and backlight levels unable to be
> altered.

I think we have two problems here:
1 No proper backlight level is set on AC plug in/out events;
2 Backlight level adjust stops working after AC plug out.

For 1, are you using any GUI environment?
For 2, do you mean by pressing the hotkey or echoing some value to the /sys/class/backlight/intel_backlight/brightness?

BTW, thanks for the bisect!
Comment 4 brent s. 2014-09-15 14:04:46 UTC
1.) Yes; GNOME 3/GNOME shell. However, the issue exhibits before the graphical component is initialized and persists in TTYs. (additionally, it persists with the graphical component disabled). Apologies; I should have mentioned that earlier. :)

2.) Both, actually; I've tried echoing various new values with no change against a working vs. non-working kernel. Expected behavior was consistent- working kernel was, well, working and vice versa. Part of it is on a non-working kernel, I only get intel_backlight as an ACPI video backlight component. On a working kernel, I get intel_backlight and acpi_video0 (or sometimes acpi_video0 and acpi_video1... it depends on the kernel version. i don't think that behaviour's *quite* relevant; it's moreso that the acpi_videoX never shows up on non-working kerenels).

The hotkey shortcut, which normally works via GNOME 3 and TTY, does not work in either on the non-working kernel (and was how I tested the majority of the bisects).
Comment 5 Aaron Lu 2014-09-16 03:00:02 UTC
(In reply to brent s. from comment #4)
> 1.) Yes; GNOME 3/GNOME shell. However, the issue exhibits before the
> graphical component is initialized and persists in TTYs. (additionally, it
> persists with the graphical component disabled). Apologies; I should have
> mentioned that earlier. :)

Never mind :-)
Your BIOS may did something on AC plug in/out and since we are disabling the acpi_video interface from v3.16, that functionality is gone now. I thought the GUI should handle that too, since GUI will get the notification on AC plug in/out and then decide to which level the backlight should be set to and it even can show a indicator on the screen to make the process more user friendly. But that of couse requires a working backlight control interface, and in v3.16's case, it is intel_backlight.

> 
> 2.) Both, actually; I've tried echoing various new values with no change
> against a working vs. non-working kernel. Expected behavior was consistent-
> working kernel was, well, working and vice versa. Part of it is on a
> non-working kernel, I only get intel_backlight as an ACPI video backlight
> component. On a working kernel, I get intel_backlight and acpi_video0 (or
> sometimes acpi_video0 and acpi_video1... it depends on the kernel version. i
> don't think that behaviour's *quite* relevant; it's moreso that the
> acpi_videoX never shows up on non-working kerenels).
> 
> The hotkey shortcut, which normally works via GNOME 3 and TTY, does not work
> in either on the non-working kernel (and was how I tested the majority of
> the bisects).

So do I understand correctly that once you have pluged out the AC adapter, the intel_backlight interface will stop working. And by working, I mean echoing a value to its brightness file has no effect any more.
Comment 6 Aaron Lu 2014-09-16 03:02:14 UTC
I just noticed, you have mentioned ATI backlight while we are talking about intel_backlight, can you please clarify this?

Please attach your lspci output and acpidump, thanks.
Comment 7 brent s. 2014-09-16 17:35:12 UTC
sure thing; sorry for the delay.

Will attach shortly with comparison of working vs. non-working kernels
Comment 8 brent s. 2014-09-16 17:39:30 UTC
Created attachment 150561 [details]
lspci and acpidump output from non-working (>3.15-rc8) kernel
Comment 9 brent s. 2014-09-16 18:54:13 UTC
Created attachment 150571 [details]
lspci and acpidump output from working (3.15-rc8) kernel
Comment 10 Aaron Lu 2014-09-17 02:21:35 UTC
One thing to clarify: when does the intel_backlight stop working? And by working, I mean echoing a value to the /sys/class/backlight/intel_backlight/brightness file has no effect any more.
Comment 11 brent s. 2014-09-17 12:16:18 UTC
the intel_backlight/brightness actually never changes, no matter what the display's brightness is. It stays at a static 4648. Perhaps it's for the keyboard's backlit keys? Not sure.

However, what DOES change when the backlight is changed is acpi_video1.
acpi_video0's brightness is always 95.

Brightness turned all the way up:

[bts@workhorse ~]$ cat /sys/class/backlight/{acpi_video{0,1},intel_backlight}/brightness 
95
95
4648


Brightness turned all the way down:

[bts@workhorse ~]$ cat /sys/class/backlight/{acpi_video{0,1},intel_backlight}/brightness 
95
0
4648

When on the "non-working" kernel versions, there IS no acpi_video0 nor acpi_video1.

As shown earlier from lspci, I have both:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] (rev ff)

(This is a Samsung ATIV Book 6 (which has a touchscreen, so that may also be relevant or not).
Comment 12 Aaron Lu 2014-09-18 01:33:37 UTC
Please test this:
# cd /sys/class/backlight/intel_backlight
# echo 1000 > brightness
# echo 2000 > brightness
...
See if backlight level changes.
Comment 13 brent s. 2014-09-18 14:24:22 UTC
In the "working" kernel:

[root@workhorse intel_backlight]# pwd ; echo 1000 > brightness ; cat brightness ; echo 2000 > brightness ; cat brightness ; echo 5 > brightness ; cat brightness
/sys/class/backlight/intel_backlight
1000
2000
5

But no actual changes to the physical display's actual brightness level.

The same exact behavior occurs in the "non-working" kernel versions.


[root@workhorse intel_backlight]# pwd ; echo 1000 > brightness ; cat brightness ; echo 2000 > brightness ; cat brightness ; echo 5 > brightness ; cat brightness
/sys/class/backlight/intel_backlight
1000
2000
5

But again with no changes to the actual brightness output.

It would seem that the intel_backlight may have more to do with an auxiliary display perhaps?


Note that in a "working" kernel I can echo different values to /sys/class/backlight/acpi_video0/brightness (and /sys/class/backlight/acpi_video1/brightness) and the brightness DOES change.

However, as stated before, neither of the acpi_videoN show up in the "non-working" kernel.
Comment 14 Aaron Lu 2014-09-19 01:37:11 UTC
OK, that means the intel_backlight doesn't work on your laptop. Please attach your dmi and I'll add your laptop to the DMI table.
# dmidecode > dmi.txt
Comment 15 brent s. 2014-09-19 02:36:32 UTC
Created attachment 150851 [details]
dmidecode output
Comment 16 Aaron Lu 2014-09-19 02:58:02 UTC
Created attachment 150861 [details]
Disable native backlight for SAMSUNG 870Z5E-880Z5E-680Z5E

Please test this patch, apply on top of v3.17-rc5 or later.
Comment 17 brent s. 2014-09-19 16:13:00 UTC
Unfortunately the boot process hangs with the included patch, though I'm not sure it's *due* to the included patch. I will attach a photo of kernel output.
Comment 18 brent s. 2014-09-19 16:18:43 UTC
Created attachment 150961 [details]
Kernel output, 3.17

built and patched against d9773ceabfaf3f27b8a36fac035b74ee599df900
Comment 19 Aaron Lu 2014-09-22 01:54:32 UTC
The hang seems to happen at the time of switching graphics mode, which is handled by GPU driver. I would suggest file a bug to Drivers/DRI-Intel for this problem and once that is fixed, we can continue test this patch here.
Comment 20 brent s. 2014-09-26 07:10:40 UTC
Apologies for the delay.

I've filed Bug #85171.
Comment 21 Aaron Lu 2014-10-11 02:16:54 UTC
That bug doesn't seem get any attention. Does the final v3.17 still hang?
Comment 22 brent s. 2014-10-11 02:23:10 UTC
Thanks for following up, Aaron. I'll give it another update and build right now and let you know.
Comment 23 brent s. 2014-10-11 23:30:28 UTC
After testing, I got the same display. However, on a hunch... I tried sshing in and the machine actually comes up, so it's not a hang.

I couldn't test at the moment, but I suspect that second video output, the Intel, is actually my auxiliary display on my laptop.

I think what instead happens is either:

1.) the ATI card (physical primary display, the laptop's screen) is never recognized/initialized/what have you during the kernel initialization

2.) the Intel card is (mistakenly) made the primary display and the ATI is ignored

or

3.) the ATI is treated as a TTY device instead of an actual display.


I'll have to do some more testing (lspci output, hooking up an external, etc.) to see what info I get, but I'm leaning towards #1 being the case- as that would explain why I never get an acpi_video(0,1) on the faulty kernels- the kernel doesn't even think the video card's there.

Any additional tests I should make, or just try an external display and get an lspci dump?
Comment 24 brent s. 2014-10-12 01:40:38 UTC
lspci:

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M]
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

seems to be the same.

i tested both vga and hdmi out, both plugging in after boot and before- neither initialize the external display, so my guess #2 above is wrong.
Comment 25 Aaron Lu 2014-10-16 08:12:58 UTC
Plase attach your acpidump:
# acpidump > acpidump.txt

Anyway, I think your problem is clear: for some reason, the GPU driver doesn't bring up your display during boot, which needs to be solved by the GPU people. Once that is fixed, restore the acpi_videoX interface should be enough for the backlight problem.

BTW, I suppose the GPU issue is new? It only starts from some kernel version? If so, please add such information to that bug page and mark it as a regression.
Comment 26 brent s. 2014-10-16 21:38:02 UTC
Created attachment 154031 [details]
output of acpidump
Comment 27 brent s. 2014-10-16 21:46:08 UTC
Submitted bug #86431

Yes, the issue is new. The GPU issue (no display) occurs starting at 3.17, this particular issue for this bug (faulty ACPI recognition) occurs starting with 3.16.0
Comment 28 Aaron Lu 2014-12-03 02:48:09 UTC
Does the below commit make your display work after boot?

commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Nov 5 14:46:31 2014 +0200

    drm/i915: safeguard against too high minimum brightness

You can test this with a v3.18-rc7 kernel, that commit should be included in v3.18-rc5 and later.
Comment 29 brent s. 2014-12-06 20:36:20 UTC
Apologies for the delay.

Unfortunately, while the commit does allow me to actually boot, the original issue still persists- I can't change the brightness levels. I have two levels- dim and (when at 0) off, no matter what value is actually set.

This is when it's working (on the 3.15.8 kernel):

[bts@workhorse backlight]$ pwd
/sys/class/backlight
[bts@workhorse backlight]$ ls
acpi_video0  acpi_video1  intel_backlight

In newer kernels, acpi_video does not show up at all.

under 3.15.8,
Brightness turned up:

[bts@workhorse backlight]$ for i in `ls -1`;do echo -n "${i}: " ; cat ${i}/brightness ; done
acpi_video0: 95
acpi_video1: 95
intel_backlight: 4648


Brightness about half-dimmed:

[bts@workhorse backlight]$ for i in `ls -1`;do echo -n "${i}: " ; cat ${i}/brightness ; done
acpi_video0: 48
acpi_video1: 95
intel_backlight: 4648



So as I've stated before, it seems that acpi_video0 (sometimes acpi_video1) is actually controlling the laptop's primary display, not intel_backlight as I've been told in Comment #6.

Would you still like me to apply the patch you provide in Comment #16?

Keep in mind, again, that when the backlight works properly and when it doesn't, intel_backlight still *never* changes. The backlight's value that DOES change when the screen is dimmed/brightened is acpi_video*.
Comment 30 brent s. 2014-12-06 20:53:29 UTC
I also tried per Bug #66501 to use kernel param acpi_backlight=vendor but this made no difference.

It also occurs that Bug #84561 appears to be a duplicate of mine, as this is also a Samsung machine and is experiencing the same behaviour.
Comment 31 Aaron Lu 2014-12-08 01:50:01 UTC
(In reply to brent s. from comment #29)
> Would you still like me to apply the patch you provide in Comment #16?

Yes, that patch is meant to restore your acpi_videoX interfaces.
Better test it on top of v3.18.
Comment 32 brent s. 2014-12-09 00:27:21 UTC
(In reply to Aaron Lu from comment #31)
> (In reply to brent s. from comment #29)
> > Would you still like me to apply the patch you provide in Comment #16?
> 
> Yes, that patch is meant to restore your acpi_videoX interfaces.
> Better test it on top of v3.18.

I can confirm that the changes in Comment #16 restore backlight control for me (and do restore the acpi_video* devices).

It seems like the brightness stepping may be a little different (the steps seem less drastic near the top of the range), but I'm pretty sure that's more to do with how I'm perceiving it rather than what's actually the case.

But yes, those changes do restore the functionality.
Comment 33 brent s. 2014-12-09 00:30:27 UTC
(whoops- forget to mention, tested against 3.18.0, commit b2776bf7149bddd1f4161f14f79520f17fc1d71d in mainline, torvalds/linux.git)
Comment 34 Aaron Lu 2014-12-19 02:48:15 UTC
Thanks brent for the test, let's track this issue in #84561.

*** This bug has been marked as a duplicate of bug 84561 ***