Bug 84221

(originally reported downstream at https://bugs.archlinux.org/task/41580 )

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).

(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!

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).

(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.

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.

sure thing; sorry for the delay.

Will attach shortly with comparison of working vs. non-working kernels

Created attachment 150561 [details]
lspci and acpidump output from non-working (>3.15-rc8) kernel

Created attachment 150571 [details]
lspci and acpidump output from working (3.15-rc8) kernel

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.

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).

Please test this:
# cd /sys/class/backlight/intel_backlight
# echo 1000 > brightness
# echo 2000 > brightness
...
See if backlight level changes.

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.

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

Created attachment 150851 [details]
dmidecode output

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.

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.

Created attachment 150961 [details]
Kernel output, 3.17

built and patched against d9773ceabfaf3f27b8a36fac035b74ee599df900

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.

Apologies for the delay.

I've filed Bug #85171.

That bug doesn't seem get any attention. Does the final v3.17 still hang?

Thanks for following up, Aaron. I'll give it another update and build right now and let you know.

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?

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.

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.

Created attachment 154031 [details]
output of acpidump

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

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.

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*.

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.

(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.

(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.

(whoops- forget to mention, tested against 3.18.0, commit b2776bf7149bddd1f4161f14f79520f17fc1d71d in mainline, torvalds/linux.git)

Thanks brent for the test, let's track this issue in #84561.

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