Bug 76491

Summary: backlight changing to maximum when plug or unplug AC
Product: ACPI Reporter: Igor Raits (igor.raits)
Component: Power-VideoAssignee: Aaron Lu (aaron.lu)
Status: CLOSED CODE_FIX    
Severity: normal CC: aaron.lu, bugzilla, igor.raits, lenb, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
See Also: https://bugzilla.gnome.org/show_bug.cgi?id=730310
Kernel Version: kernel-3.15.0-0.rc5.git2.9.fc21 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: acpidump from X1 Carbon
Work around thinkpad win8 ac change backlight problem

Description Igor Raits 2014-05-19 12:30:53 UTC
Steps to reproduce:
1. Set backlight to <100% with keyboard
2. Plug or unplug AC

Actual results:
Backlight changed to maximum

Expected results:
Backlight unchanged

Additional info:
# grep -r . /sys/class/backlight/*
/sys/class/backlight/intel_backlight/type:raw
/sys/class/backlight/intel_backlight/brightness:444
/sys/class/backlight/intel_backlight/power/control:auto
/sys/class/backlight/intel_backlight/power/async:disabled
/sys/class/backlight/intel_backlight/power/runtime_enabled:disabled
/sys/class/backlight/intel_backlight/power/runtime_active_kids:0
/sys/class/backlight/intel_backlight/power/runtime_active_time:0
grep: /sys/class/backlight/intel_backlight/power/autosuspend_delay_ms:
Input/output error
/sys/class/backlight/intel_backlight/power/runtime_status:unsupported
/sys/class/backlight/intel_backlight/power/runtime_usage:0
/sys/class/backlight/intel_backlight/power/runtime_suspended_time:0
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/max_brightness:4438
/sys/class/backlight/intel_backlight/actual_brightness:444


I think this is caused, because in my system doesn't present acpi_video0. Only
intel_backlight. But it's normal for the my system:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5915a3db0c3983f1cd5e046bf70086c7d0c686d2
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67b662e189f469c6d373f81d76b0ef0495940e99
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbc9fe1b4f222a7c575e3bd8e9defe59c6190a04
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e9f81d3b7cd0649a3bc437391b6a0650f98f844
Comment 1 Igor Raits 2014-05-19 12:32:07 UTC
CC'ing Bastien, because this bug is not in gnomt-settings-daemon. He said, that bug in kernel.
Comment 2 Bastien Nocera 2014-05-19 12:50:43 UTC
(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").
Comment 3 Igor Raits 2014-05-19 13:41:48 UTC
(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.
Comment 4 Aaron Lu 2014-05-21 01:44:20 UTC
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.
Comment 5 Igor Raits 2014-05-21 02:42:35 UTC
(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.
Comment 6 Aaron Lu 2014-05-21 02:56:27 UTC
And does it also have this problem? If so, please attach its acpidump, let's see what the firmware did.
Comment 7 Igor Raits 2014-05-21 03:31:25 UTC
Created attachment 136891 [details]
acpidump from X1 Carbon

Attached.
Comment 8 Len Brown 2014-05-21 20:15:27 UTC
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?
Comment 9 Igor Raits 2014-05-21 20:49:22 UTC
(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.
Comment 10 Aaron Lu 2014-05-28 02:41:41 UTC
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.
Comment 11 Igor Raits 2014-05-28 06:50:40 UTC
(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
Comment 12 Igor Raits 2014-05-28 08:11:44 UTC
(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.
Comment 13 Igor Raits 2014-05-28 08:45:41 UTC
3.14-rc2 works
Comment 14 Igor Raits 2014-05-28 08:57:48 UTC
3.14-rc5 has this bug
Comment 15 Aaron Lu 2014-05-28 09:06:20 UTC
Please go on to test 3.14-rc4 and if it works, start bisect between the two, thanks.
Comment 16 Igor Raits 2014-05-28 11:35:11 UTC
3.14-rc4 has this bug. testing 3.14-rc3
Comment 17 Igor Raits 2014-05-28 12:12:47 UTC
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.
Comment 18 Igor Raits 2014-05-28 12:13:18 UTC
How debug more ?
Comment 19 Aaron Lu 2014-05-29 01:33:08 UTC
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.
Comment 20 Igor Raits 2014-05-29 03:37:05 UTC
(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.
Comment 21 Igor Raits 2014-05-30 04:46:23 UTC
(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.
Comment 22 Aaron Lu 2014-05-30 06:24:05 UTC
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.
Comment 23 Aaron Lu 2014-05-30 06:24:32 UTC
(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.
Comment 24 Igor Raits 2014-05-30 06:46:44 UTC
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
Comment 25 Igor Raits 2014-05-30 06:59:43 UTC
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
Comment 26 Igor Raits 2014-05-30 07:04:08 UTC
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
Comment 28 Aaron Lu 2014-05-30 07:26:10 UTC
Not sure, you will have to try I'm afraid.
BTW, do you have thinkpad_acpi loaded?
Comment 29 Igor Raits 2014-05-30 07:35:36 UTC
(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 ?
Comment 30 Aaron Lu 2014-05-30 07:50:52 UTC
(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...
Comment 31 Aaron Lu 2014-05-30 07:52:25 UTC
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?
Comment 32 Igor Raits 2014-05-30 08:11:56 UTC
(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
Comment 33 Aaron Lu 2014-05-30 08:18:02 UTC
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.
Comment 34 Igor Raits 2014-05-30 08:26:30 UTC
(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
Comment 35 Aaron Lu 2014-05-30 08:28:34 UTC
(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.
Comment 36 Igor Raits 2014-05-30 08:37:02 UTC
With latest git (3.15) with video.use_native_backlight=0 thia bug not affects me.
Comment 37 Aaron Lu 2014-05-30 08:41:20 UTC
(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?
Comment 38 Aaron Lu 2014-05-30 08:46:14 UTC
Oh I see, your system's firmware has already fixed the acpi_video's problem.
Comment 39 Aaron Lu 2014-05-30 08:47:18 UTC
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?
Comment 40 Igor Raits 2014-05-30 08:48:45 UTC
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.
Comment 41 Igor Raits 2014-05-30 08:49:36 UTC
(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 ?
Comment 42 Aaron Lu 2014-05-30 08:52:13 UTC
With latest Linux and video.use_native_backlight=0 cmdline, the acpi_video interface is broken?
Comment 43 Igor Raits 2014-05-30 08:59:12 UTC
(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.
Comment 44 Aaron Lu 2014-05-30 09:00:53 UTC
The asle->bclp is set by firmware
Comment 45 Igor Raits 2014-05-30 09:05:34 UTC
(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.
Comment 46 Aaron Lu 2014-05-30 09:06:03 UTC
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.
Comment 47 Igor Raits 2014-05-30 09:28:27 UTC
(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.
Comment 48 Igor Raits 2014-05-30 09:38:27 UTC
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.
Comment 49 Aaron Lu 2014-05-30 10:35:56 UTC
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.
Comment 50 Igor Raits 2014-05-30 17:38:56 UTC
(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.
Comment 51 Aaron Lu 2014-06-03 01:28:05 UTC
(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?
Comment 52 Zhang Rui 2014-06-05 02:23:15 UTC
*** Bug 77091 has been marked as a duplicate of this bug. ***
Comment 53 Igor Raits 2014-06-05 04:31:26 UTC
(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.
Comment 54 Igor Raits 2014-06-05 05:17:00 UTC
But 3.13-rc0+ has this problem.
Comment 55 Aaron Lu 2014-06-05 05:50:14 UTC
Which kernel doesn't have this problem if intel_backlight is in use?
Comment 56 Zhang Rui 2014-06-05 06:56:08 UTC
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.
Comment 57 Igor Raits 2014-06-05 07:21:07 UTC
(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.
Comment 58 Aaron Lu 2014-06-05 07:31:46 UTC
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.
Comment 59 Igor Raits 2014-06-05 14:37:27 UTC
(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.
Comment 60 Aaron Lu 2014-06-06 05:28:32 UTC
BTW, do you have Windows? Does it also have this problem?
Comment 61 Igor Raits 2014-06-06 05:55:53 UTC
(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.
Comment 62 Aaron Lu 2014-06-06 06:01:41 UTC
(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.
Comment 63 Igor Raits 2014-06-06 10:08:01 UTC
Installing windows for testing.
Comment 64 Igor Raits 2014-06-06 12:31:34 UTC
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
Comment 65 Aaron Lu 2014-06-10 00:57:03 UTC
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.
Comment 66 Aaron Lu 2014-06-10 00:57:39 UTC
Thanks for testing!
Comment 67 Igor Raits 2014-06-10 03:29:43 UTC
(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!
Comment 68 Aaron Lu 2014-06-24 02:37:58 UTC
Patch sent out:
https://patchwork.kernel.org/patch/4406151/
Comment 69 Aaron Lu 2015-01-06 07:38:41 UTC
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