CC'ing Bastien, because this bug is not in gnomt-settings-daemon. He said, that bug in kernel.

(In reply to Igor Gnatenko from comment #1)
> CC'ing Bastien, because this bug is not in gnomt-settings-daemon. He said,
> that bug in kernel.

Not quite, I said that it's likely a firmware bug that could be mitigated in the kernel (maybe with the kernel disabling that "feature").

(In reply to Bastien Nocera from comment #2)
> (In reply to Igor Gnatenko from comment #1)
> > CC'ing Bastien, because this bug is not in gnomt-settings-daemon. He said,
> > that bug in kernel.
> 
> Not quite, I said that it's likely a firmware bug that could be mitigated in
> the kernel (maybe with the kernel disabling that "feature").

Oh. Soery for this inaccuracy.



I can reproduce this on X1 Carbon and X230. In BGO I see that this issue present on T520.

Is this a Win8 system? We have already set the bit2 of _DOS control method to tell BIOS not to change brightness level on AC to DC.

(In reply to Aaron Lu from comment #4)
> Is this a Win8 system? We have already set the bit2 of _DOS control method
> to tell BIOS not to change brightness level on AC to DC.

Yep, one of two of those.

And does it also have this problem? If so, please attach its acpidump, let's see what the firmware did.

Created attachment 136891 [details]
acpidump from X1 Carbon

Attached.

Why is this marked as a kernel regression?

What is the most recent kernel that works properly?
What is the oldest kernel that does not work properly?

(In reply to Len Brown from comment #8)
> Why is this marked as a kernel regression?
> 
> What is the most recent kernel that works properly?
> What is the oldest kernel that does not work properly?

It 100% worked early. When I've tested Aaron's patchset for backlight it worked. 

I could bisect, but only at this weekend.

Any update on the bisect?

Also, please enable backlight debug messages after boot like this:
# cd /sys/kernel/debug/dynamic_debug
# echo 'module backlight +fpt' > control
And then plug/unplug ac, see if any message showed up in dmesg.

(In reply to Aaron Lu from comment #10)
> Any update on the bisect?
Unfortunately, I've not started it. I hope will do it today. :(
> Also, please enable backlight debug messages after boot like this:
> # cd /sys/kernel/debug/dynamic_debug
> # echo 'module backlight +fpt' > control
> And then plug/unplug ac, see if any message showed up in dmesg.
May 28 10:49:28 X1Carbon.localdomain kernel: thinkpad_acpi: EC reports that Thermal Table has changed

(In reply to Aaron Lu from comment #10)
> Any update on the bisect?
http://koji.fedoraproject.org/koji/buildinfo?buildID=492921
works. Linux v3.13-737-g7fe67a1

I'll test more builds and I'll find bad commit. Give me 2 days.

3.14-rc2 works

3.14-rc5 has this bug

Please go on to test 3.14-rc4 and if it works, start bisect between the two, thanks.

3.14-rc4 has this bug. testing 3.14-rc3

3.14-rc3 hasn't this bug. I can't compile kernels today, but I think:
$ git log v3.14-rc3..v3.14-rc4 --pretty=oneline --grep backlight
726734299582303f72a422ee6540a63e474f4b01 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
795233bfd65916a7d1d3b086f056bd7af03c50fe Merge tag 'pm+acpi-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
d8ad344cb445627687fb44769e2ed89f93d3f06b Merge branches 'acpi-pm' and 'acpi-video'
a6940190ac15c361862a1a8f50a2072db7184749 Revert "ACPI: Blacklist Win8 OSI for some HP laptop 2013 models"
0e9f81d3b7cd0649a3bc437391b6a0650f98f844 ACPI / video: Add systems that should favour native backlight interface
bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 ACPI / video: Filter the _BCL table for duplicate brightness values
110720fe57faa9aa8954ac40f56607f1184378b3 Merge tag 'pwm_pxa_for_v3.14' of https://git.kernel.org/pub/scm/linux/kernel/git/hzhuang1/linux into fixes
902e6a0c7eba08ec978cea8304c6cb2ddce7b9dc ARM: pxa: Add dummy backlight power supply on Mitac Mio A701


I think this caused by switching to intel_backlight.

How debug more ?

If you think this is due to switching to intel_backlight, you can boot the kernel with video.use_native_backlight=0 to force keep the acpi_video interface and then test. But since user space doesn't send any brightness level change on AC pulg/unplug(as we have tested with the dynamic_debug), I don't see how switching to intel_backlight would affect this. Anyway, please give it a test.

(In reply to Aaron Lu from comment #19)
> If you think this is due to switching to intel_backlight, you can boot the
> kernel with video.use_native_backlight=0 to force keep the acpi_video
> interface and then test. But since user space doesn't send any brightness
> level change on AC pulg/unplug(as we have tested with the dynamic_debug), I
> don't see how switching to intel_backlight would affect this. Anyway, please
> give it a test.

ok. Thanks! I'll test use_native_backlight=0 and if it will not fix problem - I'll bisect.

(In reply to Aaron Lu from comment #19)
> If you think this is due to switching to intel_backlight, you can boot the
> kernel with video.use_native_backlight=0 to force keep the acpi_video
> interface and then test. But since user space doesn't send any brightness
> level change on AC pulg/unplug(as we have tested with the dynamic_debug), I
> don't see how switching to intel_backlight would affect this. Anyway, please
> give it a test.

yes. video.use_native_backlight=0 fixes problem, but there problem with backlight (not full range) again affect me.

I really don't have any idea why using intel_backlight would cause this. Can you please boot with drm.debug=0x2 and then unplug AC to see if anything new appeared in dmesg? thanks.

(In reply to Aaron Lu from comment #22)
> I really don't have any idea why using intel_backlight would cause this. Can
> you please boot with drm.debug=0x2 and then unplug AC to see if anything new
> appeared in dmesg? thanks.

Without the video.use_native_backlight=0 cmdline option of course.

May 30 10:46:13 X1Carbon.localdomain kernel: [drm:asle_set_backlight] bclp = 0x800000ff
May 30 10:46:13 X1Carbon.localdomain kernel: [drm:intel_panel_actually_set_backlight] set backlight PWM = 4438
May 30 10:46:13 X1Carbon.localdomain kernel: [drm:asle_set_pwm_freq] PWM freq is not supported
May 30 10:46:14 X1Carbon.localdomain kernel: thinkpad_acpi: EC reports that Thermal Table has changed

With drm.debug=0x4

[   55.739305] [drm:asle_set_backlight] updating opregion backlight 255/255
[   56.346931] thinkpad_acpi: EC reports that Thermal Table has changed

Can this[0] commit be regression in intel_backlight thing ?

[0]https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=752aa88a1e784c22d514db3b440e49427b58259e

Or this:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/intel_opregion.c?id=c91c9f32843a1b433de5a1ead4789a6bc8d3d914

Not sure, you will have to try I'm afraid.
BTW, do you have thinkpad_acpi loaded?

(In reply to Aaron Lu from comment #28)
> Not sure, you will have to try I'm afraid.
ok
> BTW, do you have thinkpad_acpi loaded?
yes. it's in my loaded modules. try to unload ?

(In reply to Igor Gnatenko from comment #29)
> (In reply to Aaron Lu from comment #28)
> > Not sure, you will have to try I'm afraid.
> ok
> > BTW, do you have thinkpad_acpi loaded?
> yes. it's in my loaded modules. try to unload ?

No, it should be loaded :-)

From the dmesg, on AC plug/unplug, there is indeed firmware request to set backlight level.

Checking the acpi table again. It should be _Q26 and _Q27 for AC events and the backlight setting is called unconditionally there. I don't see how can we solve this problem...

I don't understand why you don't have this problem earlier, since that firmware call is always there. Unless the intel_backlight interface doesn't work for you in earlier kernel version?

(In reply to Aaron Lu from comment #31)
> I don't understand why you don't have this problem earlier, since that
> firmware call is always there. Unless the intel_backlight interface doesn't
> work for you in earlier kernel version?
How I can force use intel_backlight in (for example) 3.13 ? There IIRC no video.use_native_backlight=1.. _OSI=WIN8 didnt works for me, because bug in kernel or grub2-efi

Echo a value to /sys/class/backlight/intel_backlight/brightness to test if intel_backlight works. The firmware will simply trigger an interrupt on AC plug/unplug for i915 to handle, so if intel_backlight works previously I don't understand why AC plug/unplug don't cause problem on previous kernels.

(In reply to Aaron Lu from comment #33)
> Echo a value to /sys/class/backlight/intel_backlight/brightness to test if
> intel_backlight works. The firmware will simply trigger an interrupt on AC
> plug/unplug for i915 to handle, so if intel_backlight works previously I
> don't understand why AC plug/unplug don't cause problem on previous kernels.

for clarify:
3.14-rc3- works with acpi_video0 without this bug
3.14-rc4+ works with intel_backlight with this bug

I've not tested 3.14-rc3- with intel_backlight, because I can't add to bootloader something related with acpi _OSI_WIN8.

Now I will boot to 3.13-rc0 with acpi_video0, echo a value to /sys/class/backlight/intel_backlight/brightness and try to plug/unplug.

Also will try boot with:
acpi_osi="!Windows 2012"
acpi_backlight=legacy
acpi_osi=Linux

(In reply to Igor Gnatenko from comment #34)
> for clarify:
> 3.14-rc3- works with acpi_video0 without this bug
> 3.14-rc4+ works with intel_backlight with this bug
> 
> I've not tested 3.14-rc3- with intel_backlight, because I can't add to
> bootloader something related with acpi _OSI_WIN8.

You do not need to pass anything, the intel_backlight should always be there: /sys/class/backlight/intel_backlight.

With latest git (3.15) with video.use_native_backlight=0 thia bug not affects me.

(In reply to Igor Gnatenko from comment #36)
> With latest git (3.15) with video.use_native_backlight=0 thia bug not
> affects me.

But can you adjust backlight with hotkey using this config? I suppose the acpi_video interface is broken?

Oh I see, your system's firmware has already fixed the acpi_video's problem.

So your system doesn't need to be in video's quirk table now, is it that you update your BIOS or I don't know why it is in video's quirk table in the first place?

setted with hotkeys backlight (2 keys pressed):
[brain@X1Carbon ~]$ cat /sys/class/backlight/acpi_video0/brightness 
50
[brain@X1Carbon ~]$ cat /sys/class/backlight/intel_backlight/brightness 
663
[  167.796118] [drm:asle_set_backlight], bclp = 0x8000001d
[  167.796127] [drm:intel_panel_get_max_backlight], max backlight PWM = 4438
[  167.796130] [drm:intel_panel_actually_set_backlight], set backlight PWM = 493
[  167.796134] [drm:asle_set_pwm_freq], PWM freq is not supported
[  167.853686] [drm:asle_set_backlight], bclp = 0x80000027
[  167.853697] [drm:intel_panel_get_max_backlight], max backlight PWM = 4438
[  167.853700] [drm:intel_panel_actually_set_backlight], set backlight PWM = 663
[  167.853704] [drm:asle_set_pwm_freq], PWM freq is not supported


setted to intel_bcaklight value:
[brain@X1Carbon ~]$ echo 500 | sudo tee /sys/class/backlight/intel_backlight/brightness 
500
[brain@X1Carbon ~]$ cat /sys/class/backlight/acpi_video0/brightness 
50
[brain@X1Carbon ~]$ cat /sys/class/backlight/intel_backlight/brightness 
500
[  272.280150] [drm:intel_panel_get_max_backlight], max backlight PWM = 4438
[  272.280155] [drm:intel_panel_actually_set_backlight], set backlight PWM = 500


unplugged AC:
[brain@X1Carbon ~]$ cat /sys/class/backlight/acpi_video0/brightness 
50
[brain@X1Carbon ~]$ cat /sys/class/backlight/intel_backlight/brightness 
663
[  335.667432] [drm:asle_set_backlight], bclp = 0x80000027
[  335.667440] [drm:intel_panel_get_max_backlight], max backlight PWM = 4438
[  335.667441] [drm:intel_panel_actually_set_backlight], set backlight PWM = 663
[  335.667444] [drm:asle_set_pwm_freq], PWM freq is not supported

Tested on kernel: Linux version 3.13.0-0.rc0.git1.3.fc21.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC) ) #1 SMP Mon Nov 11 19:24:44 UTC 2013



I think intel_backlight don't setting correct asle->bclp.

(In reply to Aaron Lu from comment #39)
> So your system doesn't need to be in video's quirk table now, is it that you
> update your BIOS or I don't know why it is in video's quirk table in the
> first place?
now acpi_video broken for me. I should update bios ?

With latest Linux and video.use_native_backlight=0 cmdline, the acpi_video interface is broken?

(In reply to Aaron Lu from comment #42)
> With latest Linux and video.use_native_backlight=0 cmdline, the acpi_video
> interface is broken?

yes. it works, but not full range.

http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/g6uj14uc.txt

there no info about fixing this bug in BIOS.

The asle->bclp is set by firmware

(In reply to Aaron Lu from comment #44)
> The asle->bclp is set by firmware

As you can see above, when I changing acpi_video0 - in dmesg i see something about bclp, but when I'm changing intel_backlight nothing about bclp in logs.

Take a look comment 40.

There are a bunch of asl code which is called on AC plug/unplu that I don't quite understand, so it's not easy for me to figure out a workaround now. The end result of those asl code is to trigger asle interrupt with bclp set by firmware. I can see why brightness level changes on AC plug/unplug but I don't see why it doesn't happen always but only after some kernel version. Maybe the bisect could give us more hint about this.

(In reply to Aaron Lu from comment #46)
> There are a bunch of asl code which is called on AC plug/unplu that I don't
> quite understand, so it's not easy for me to figure out a workaround now.
> The end result of those asl code is to trigger asle interrupt with bclp set
> by firmware. I can see why brightness level changes on AC plug/unplug but I
> don't see why it doesn't happen always but only after some kernel version.
> Maybe the bisect could give us more hint about this.

Ok. I'll try 3.12, 3.11, 3.10, 3.9. 3.8.

After testing - I will let you know.

Also with 3.13(acpi_video) it don't affect me with basic usage. Only if I will change intel_backlight after plug/unplug AC it will reset to previous.

No need to test old kernels. You have tested v3.14-rc3 works and v3.14-rc4 doesn't, just bisect between the two is OK.

(In reply to Aaron Lu from comment #49)
> No need to test old kernels. You have tested v3.14-rc3 works and v3.14-rc4
> doesn't, just bisect between the two is OK.

I think you are wrong.

I can reproduce this bug with rc3, but only when I manual set intel_backlight. If I will set 70% backlight with hotkeys(acpi_video), echo 100 to intel_backlight and plug/unplug AC it will return me to 70%. Intel_backlight will also resetted to previous value.

(In reply to Igor Gnatenko from comment #50)
> (In reply to Aaron Lu from comment #49)
> > No need to test old kernels. You have tested v3.14-rc3 works and v3.14-rc4
> > doesn't, just bisect between the two is OK.
> 
> I think you are wrong.
> 
> I can reproduce this bug with rc3, but only when I manual set
> intel_backlight. If I will set 70% backlight with hotkeys(acpi_video), echo
> 100 to intel_backlight and plug/unplug AC it will return me to 70%.
> Intel_backlight will also resetted to previous value.

Oh yes, this explains what I've seen from the firmware table: on AC plug/unplug, firmware will send a backlight change request to GPU driver and from your result, the level it uses is the level acpi_video has. So all kernels have this problem right? Is there a kernel that you have tested that do not have such a problem?

*** Bug 77091 has been marked as a duplicate of this bug. ***

(In reply to Aaron Lu from comment #51)
> (In reply to Igor Gnatenko from comment #50)
> > (In reply to Aaron Lu from comment #49)
> > > No need to test old kernels. You have tested v3.14-rc3 works and
> v3.14-rc4
> > > doesn't, just bisect between the two is OK.
> > 
> > I think you are wrong.
> > 
> > I can reproduce this bug with rc3, but only when I manual set
> > intel_backlight. If I will set 70% backlight with hotkeys(acpi_video), echo
> > 100 to intel_backlight and plug/unplug AC it will return me to 70%.
> > Intel_backlight will also resetted to previous value.
> 
> Oh yes, this explains what I've seen from the firmware table: on AC
> plug/unplug, firmware will send a backlight change request to GPU driver and
> from your result, the level it uses is the level acpi_video has. So all
> kernels have this problem right? Is there a kernel that you have tested that
> do not have such a problem?

I will test today some kernels and will write after that.

But 3.13-rc0+ has this problem.

Which kernel doesn't have this problem if intel_backlight is in use?

please reboot the kernel with boot option acpi_osi="!Windows 200" and check if ACPI backlight interface works perfectly for you or not, and if the problem still exists.

(In reply to Zhang Rui from comment #56)
> please reboot the kernel with boot option acpi_osi="!Windows 200" and check
> if ACPI backlight interface works perfectly for you or not, and if the
> problem still exists.

I can't, because bug in grub2-efi or kernel. See above in one of comments.

Created attachment 138201 [details]
Work around thinkpad win8 ac change backlight problem

I just have an idea: since the firmware is crazy to change the backlight on ac plug/unplug through operation region, we can ignore the request in operation region code. Please test the patch, apply on top of v3.15-rc8 or maybe other kernel versions.

(In reply to Aaron Lu from comment #58)
> Created attachment 138201 [details]
> Work around thinkpad win8 ac change backlight problem
> 
> I just have an idea: since the firmware is crazy to change the backlight on
> ac plug/unplug through operation region, we can ignore the request in
> operation region code. Please test the patch, apply on top of v3.15-rc8 or
> maybe other kernel versions.

Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>

Thank you! This patch fixes my problem.

BTW, do you have Windows? Does it also have this problem?

(In reply to Aaron Lu from comment #60)
> BTW, do you have Windows? Does it also have this problem?
I don't have windows. If you want - I can boot to live windows.

(In reply to Igor Gnatenko from comment #61)
> (In reply to Aaron Lu from comment #60)
> > BTW, do you have Windows? Does it also have this problem?
> I don't have windows. If you want - I can boot to live windows.

If that's convenient, please give it a shot. Thanks.

Installing windows for testing.

Fucking windows can't install to USB. Wiyh live it can't install drivers for powermanagement. Without it I can't change backlight level.

So, I can't test it on Windowz

Will send the patch out when v3.16 merge window closed as the maintainers are busy dealing with merge stuffs and do not have time dealing with this right now I think.

Thanks for testing!

(In reply to Aaron Lu from comment #65)
> Will send the patch out when v3.16 merge window closed as the maintainers
> are busy dealing with merge stuffs and do not have time dealing with this
> right now I think.

Ok. NP. Thank you!

Patch sent out:
https://patchwork.kernel.org/patch/4406151/

commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Mon Jul 7 15:43:51 2014 +0800

    ACPI / i915: ignore firmware requests for backlight change