Bug 52951

Summary: ASUS N56VZ screen brightness keys not working
Product: ACPI Reporter: Micael Dias (kam1kaz3)
Component: Power-VideoAssignee: Aaron Lu (aaron.lu)
Status: CLOSED CODE_FIX    
Severity: normal CC: aaron.lu, ashjas, bob.ziuchkovski, dan.garton, derroeser, felipe.contreras, gentoo, igor.raits, miaousami, nur.kholis.majid
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.8 git Subsystem:
Regression: No Bisected commit-id:
Attachments: Original DSDT table (BIOS v 216)
acpidump
Let OS handle brightness level
dmesg from v3.8 with patch from comment #19
Add some debug print statement in acpi video module
dmesg from v3.8 with patch from comment #19 and comment #44
dmesg from aarons kernel with acpi fixes
dmesg from aarons kernel with acpi fixes
dmesg from aarons kernel with acpi fixes
dmesg from aarons kernel with acpi fixes and video.* flags
dmesg from aarons kernel with acpi fixes
Add debug statement in intel backlight setting function
Test quirk
Test quirk (v2)
attachment-17108-0.html
acpidump N56VZ BIOS215

Description Micael Dias 2013-01-23 17:53:04 UTC
Screen brightness keys don't do anything on my Asus N56VZ notebook.

I tried the various "acpi_osi" and "acpi_backlight" options and the only thing that kind of works is passing "acpi_osi=" (empty) as a kernel option, but all this does is letting the BIOS handle the brightness itself. Therefore I don't get the "pretty" notifications of screen brightness changes.

The key command never seems to reach linux. I have tried "xev", cat /dev/input/eventX and even modifying the asus-wmi module to print messages of the commands it receives, and it doesn't receive the screen brightness key commands. It does receive all others though.

I have yet to notice any weird behaviour resulting from "acpi_osi=" argument, but it could be a problem later.

I have tried to use a modified DSDT table to remove OS checks on the screen brightness key methods and try several tricks like emitting a specific brightness code (just like the other simpler Fn keys do) to no avail. To make sure the methods are being called I tried to make the brightness keys change the volume instead, and it works.
Comment 1 Micael Dias 2013-01-23 18:08:24 UTC
acpi_listen only reports events if kernel booted with "acpi_osi=".
Comment 2 Micael Dias 2013-01-23 18:15:01 UTC
Created attachment 91741 [details]
Original DSDT table (BIOS v 216)

Brightness keys are methods _Q0E and _Q0F.
Comment 3 Micael Dias 2013-01-23 18:21:11 UTC
I suspect the problem comes from the method STBR from the DSDT table, on the line that reads "If (LNotEqual (MSOS (), OSEG))" (line 17019) which basically means "if( OS != Linux )", though I haven't had the time yet to verify.
Comment 4 Micael Dias 2013-01-24 03:17:12 UTC
I have found that booting with acpi_osi="!Windows 2012" also produces the same result as "acpi_osi=".

Debugging the DSDT tables showed that when linux reports that it supports Windows8 OSI, the method "GFX0.AINT" from the DSDT tables never gets called because there is a condition that tests for windows8 non-presence just before that's called.
Comment 5 Micael Dias 2013-01-24 15:17:38 UTC
When I use acpi_osi= or acpi_osi="!Windows 2012" I can see commands being issued with apci_listen when I press the brightness keys. 
The correct messages also reach asus_wmi_notif, though I don't get anything with xev. I don't know what else to test.
Comment 6 Jose 2013-01-30 21:12:05 UTC
I have the same bug with a Toshiba Portege R930. Booting with acpi_osi="!Windows 2012" fixes the regression on kernel 3.8rc5 (this bug was not there with kernel 3.4)
Comment 7 Aaron Lu 2013-02-21 03:23:57 UTC
Hi Micael and Jos,

Thanks for the report!

Is it possible for you to test from which kernel does the bug appear? Jos mentioned 3.4 works, what about 3.5/6/7?
Comment 8 Jose 2013-02-21 21:58:21 UTC
I think 3.7 kernel had the same bug when my distro provided it. But as it was a few months ago, I'm not sure. I can bisect the kernel commit that changed this behaviour if someone points me a quick to do that.

Another workaround I have found : acpi_backlight=vendor . But then dimming too low the light shuts down.
Comment 9 Micael Dias 2013-02-22 05:23:15 UTC
I just installed LTS 3.0.65 to test, but it doesn't work very well here (I get screen corruption nd system lock up after a few seconds).

I didn't manage to change the brightess either with or without the acpi_osi="!Windows 2012" trick in the few seconds I had the system running.
Comment 10 Dan Garton 2013-03-16 17:33:26 UTC
I have an Asus N56VJ and I confirm the same behaviour on recent git kernel.org builds, 3.8.0 and 3.9.0rc1.

I'm happy to test any suggested patches.
Comment 11 Aaron Lu 2013-03-18 02:58:36 UTC
(In reply to comment #5)
> When I use acpi_osi= or acpi_osi="!Windows 2012" I can see commands being
> issued with apci_listen when I press the brightness keys. 

Do you mean acpi_listen printed out the KEY_BRIGHTNESSUP/DOWN event when you pressed the Fn key to up/down the brightness level?

I don't see anywhere in the dsdt table PEGP gets notified about brightness level change though... perhaps the hotkey is mapped by asus-wmi module, but then xev should be able to receive it, if acpid can receive it.

> The correct messages also reach asus_wmi_notif, though I don't get anything
> with xev. I don't know what else to test.
Comment 12 Ashish 2013-04-05 16:04:50 UTC
this bug affects me on ubuntu 13.04 beta with 3.8.0-15-generic kernel on asus N56VZ.
Comment 13 Aaron Lu 2013-04-07 01:25:21 UTC
lspci output please.

And next time, please attach the output of acpidump, thanks.
Comment 14 Ashish 2013-04-07 03:03:29 UTC
Created attachment 97611 [details]
acpidump

acpidump log for asus N56VZ/VJ
Comment 15 Ashish 2013-04-07 03:05:28 UTC
I have attached acpidump output as an attachment.please check.
thanks for the support.
lspci output:

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: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.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (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 VGA compatible controller: NVIDIA Corporation Device 0de3 (rev a1)
03:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
04:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10)
Comment 16 Aaron Lu 2013-04-07 03:07:24 UTC
Hi Ashish,

Thanks for the information!

BTW, I saw this system has two vga controllers, which one are you using then?
Comment 17 Ashish 2013-04-07 04:11:56 UTC
this notebook has nvdia 635M optimus along with intel hd4000
i am not using bumblebee or proprietary nvdia drivers.so by default intel HD4000 is being used.
Thanks.
Comment 18 Aaron Lu 2013-04-11 02:36:50 UTC
Hi Jos,
Your system is different, please feel free to open a new bug, thanks.

Hi all other N56VZ/VJ users,
Let me get some more info.

1 please list /sys/class/backlight
2 does manually change the brightness value affect brightness?
# cd /sys/class/backlight/acpi_video0
# echo 3 > brightness
Brightness change?
Comment 19 Aaron Lu 2013-04-11 02:41:31 UTC
Created attachment 98031 [details]
Let OS handle brightness level

Hi,

A correction to my comment #11, the table indeed notified GFX0, but we need a small change to the current driver to make the firmware deliver the notification to acpi video driver. Please apply this patch on top of either v3.8 or Linus' git tree, and then test it by pressing the hotkey, see what happened. Thanks.
Comment 20 Ashish 2013-04-11 04:31:33 UTC
Hello.. i dont have access to my system right now but i can be 100% sure of the following informarion:

1 please list /sys/class/backlight:
ls /sys/class/backlight/
intel_video (100%)
acpi_video (not sure of acpi_video or acpi_video0)



2 does manually change the brightness value affect brightness?
i dont understand what manually means in this context.. but.. keys wont reduce the brightness lesser than 90% i.e the key affect only 90% or 100%
see this to get the idea:http://www.youtube.com/watch?v=cKn6bnZgRtI
 but i could set the brightness of the screen from 0-100% using the brightness slider in the ubuntu display settings. and i confirm that this slider used to affect the value in /sys/class/backlight/acpi_video0 or acpi_video.

# cd /sys/class/backlight/acpi_video0
# echo 3 > brightness
Brightness change?

No the brightness does not change upon manually doing in root mode from a terminal.. but i remember putting a lower value in /etc/rc.local lead to a lesser brightness when ubuntu is booted, i did this so that during startup i am not greeted with a screen at full brightness, but that resulted into the brightness slider in the ubuntu settings render ineffective in setting the brightness thereafter..i.e once it is set it remains fixed throughout the ubuntu session.

Thanks.
Comment 21 Aaron Lu 2013-04-11 05:29:35 UTC
Hi Ashish,

Can you please try this patch:
https://patchwork.kernel.org/patch/2402511/

And only this one, no need for the one in comment #19, then see if hotkey works, thanks.
Comment 22 Aaron Lu 2013-04-11 05:33:56 UTC
Please follow the below steps to test that patch:

$ git clone http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
$ git checkout linux-next
$ git apply "that_patch"
$ build the kernel and test

Thanks.
Comment 23 Ashish 2013-04-11 06:44:46 UTC
@Aaron Lu.. i would have loved to test this patch.. but unfortunately my notebook is not booting,, need to send it to asus support.
Sorry.. but i will tell people on the notebookforum where people interested in testing the patch can follow up here.

Thanks.
Comment 24 Dan Garton 2013-04-11 23:26:00 UTC
@Aaron:

This is what I report on my Asus N56VJ.

I've just installed Ubuntu 13.04 beta 64bit, running Ubuntu kernel 3.8.0-17.27 (apparently based off 3.8.5).
Working better than ever before, definitely - the fn-f5 and fn-f6 buttons now ACTUALLY doing something out-of-the-box for the first time - though the range is only between 85% and 96% according to `cat /sys/class/backlight/acpi_video0/brightness`, only those two discrete values.
(Ubuntu settings panel brightness control works fine, 0-100%. No dimming on battery discharge though :( )


root@guava:~# ls -al /sys/class/backlight/
total 0
lrwxrwxrwx  1 root root 0 Apr 12 00:10 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
lrwxrwxrwx  1 root root 0 Apr 12 00:14 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight


echo x > /sys/class/backlight/acpi_video0/brightness

also works fine, values 0-100.


Anything else you want me to test?
Comment 25 Aaron Lu 2013-04-12 01:41:05 UTC
Thanks Dan.

> I've just installed Ubuntu 13.04 beta 64bit, running Ubuntu kernel
> 3.8.0-17.27
> (apparently based off 3.8.5).
> Working better than ever before, definitely - the fn-f5 and fn-f6 buttons now
> ACTUALLY doing something out-of-the-box for the first time - though the range

When you press the hotkey, do you see the indication presented by gnome to show brightness change? Or the brightness just change without any indication?

> is only between 85% and 96% according to `cat
> /sys/class/backlight/acpi_video0/brightness`, only those two discrete values.

That probably is due to the broken implementation of _BQC in this system's BIOS.

> (Ubuntu settings panel brightness control works fine, 0-100%. No dimming on
> battery discharge though :( )

Linux currently does not support this feature, it relies on BIOS, if BIOS doesn't handle this, then this is the expected behaviour.
Comment 26 Dan Garton 2013-04-12 14:56:49 UTC
@Aaron:

> When you press the hotkey, do you see the indication presented by gnome to
> show
> brightness change? Or the brightness just change without any indication?

It changes _with_ indication. Which is great.


> Linux currently does not support this feature, it relies on BIOS, if BIOS
> doesn't handle this, then this is the expected behaviour.

Really? I just meant the standard action of dimming the screen when the power adaptor is unplugged. This is probably done by power management daemon in Ubuntu (so probably irrelevant to this bug).


Any other tests/kernels/patches, please send my way.
Comment 27 Micael Dias 2013-04-12 21:47:10 UTC
(In reply to comment #11)
> (In reply to comment #5)
> > When I use acpi_osi= or acpi_osi="!Windows 2012" I can see commands being
> > issued with apci_listen when I press the brightness keys. 
> 
> Do you mean acpi_listen printed out the KEY_BRIGHTNESSUP/DOWN event when you
> pressed the Fn key to up/down the brightness level?
> 
> I don't see anywhere in the dsdt table PEGP gets notified about brightness
> level change though... perhaps the hotkey is mapped by asus-wmi module, but
> then xev should be able to receive it, if acpid can receive it.

This is what I get from acpi_listen:
~ ❯❯❯ sudo acpi_listen
 PNP0C14:01 000000ff 00000000
 PNP0C14:01 000000ff 00000000

That's a "brightness up" and "brightness down" key press. Pressing the keyboard light keys also show the same exact output (but this works, with gnome indication too).

(In reply to comment #18)
> Hi all other N56VZ/VJ users,
> Let me get some more info.
> 
> 1 please list /sys/class/backlight
> 2 does manually change the brightness value affect brightness?
> # cd /sys/class/backlight/acpi_video0
> # echo 3 > brightness
> Brightness change?

1. I have "acpi_video0", "acpi_video1" and "intel_backlight" on /sys/class/backlight when I boot without special flags. With the "!Windows 2012" flag I have "acpi_video0" and "intel_backlight" only.

2. Yes, but only on "intel_backlight", others do nothing. Just to be clear, changing "/sys/class/backlight/acpi_video0/brightness" does not do anything.(In 

reply to comment #21)
> Hi Ashish,
> 
> Can you please try this patch:
> https://patchwork.kernel.org/patch/2402511/
> 
> And only this one, no need for the one in comment #19, then see if hotkey
> works, thanks.

I also tried this patch, and it failed to apply the second part. However I changed the patch to be able to apply it successfuly, but it still doesn't solve the problem. Brightness can only only be changed with "!Windows 2012" flag.
Comment 28 Hoyt Duff 2013-04-15 18:32:44 UTC
From looking at acconfig.h, the Linux kernel still identifies itself as "Windows NT", not "Windows 8" as was mentioned in another bug report.

The following used to be in uteval.c, but has been removed. I don't know where it is found now. From the older uteval.c, these are possible vales of acpi_osi_name=

           
74         {"Windows 2000", ACPI_OSI_WIN_2000},    /* Windows 2000 */
75         {"Windows 2001", ACPI_OSI_WIN_XP},      /* Windows XP */
76         {"Windows 2001 SP1", ACPI_OSI_WIN_XP_SP1},      /* Windows XP SP1 */
77         {"Windows 2001.1", ACPI_OSI_WINSRV_2003},       /* Windows Server 2003 */
78         {"Windows 2001 SP2", ACPI_OSI_WIN_XP_SP2},      /* Windows XP SP2 */
79         {"Windows 2001.1 SP1", ACPI_OSI_WINSRV_2003_SP1},       /* Windows Server 2003 SP1 - Added 03/2006 */
80         {"Windows 2006", ACPI_OSI_WIN_VISTA},   /* Windows Vista - Added 03/2006 */

I suppose you could add "Windows 2012" for Windows 8 to that list. "Microsoft Windows" will spoof for Windows 98. For a number of historical reasons, passing "Linux" will spoof as Windows NT (blame Bill Gates).

You can pass any of these values on the GRUB command line, but if the value you are passing is not found in your ACPI BIOS, it will default to the ACPI BIOS default, whatever that is. Since "!Windows 2012" is not a valid choice, this is what's happening to you and we have no idea what the default choice is of your ACPI BIOS.

You can determine what specific OS versions your BIOS supports by disassembling the ACPI BIOS as per the instructions at http://forums.opensuse.org/archives/sf-archives/archives-tips-tricks-tweaks/320199-howto-fix-your-buggy-dsdt.html and searching for "Windows' in the resulting text file. With very new hardware, you should disassemble the ACPI BIOS to make certain what it actually supports. As a bonus, you may be able to "fix" it as sometimes the problem is just an obvious typo in the code.

I have experienced the best ACPI behavior by passing
acpi_osi_name="Windows 2001" and add it to all my GRUB boot parameters
but again, it depends on your specific BIOS. 

So my suggestion is to at least try acpi_osi_name="Windows 2001", which spoofs for Windows XP as opposed to what you are doing (which is to invoke the unknown BIOS default). If you hardware is newer, spoof for Vista instead.
Comment 29 Hoyt Duff 2013-04-15 18:55:38 UTC
Or you could even try spoofing as "Windows 2012" since the default behavior is for Linux to spoof as Windows NT.
Comment 30 Hoyt Duff 2013-04-15 18:59:13 UTC
And the Mageia3 Errata page should be changed to reflect the incorrect ACPI spoofing behavior information found there.

https://wiki.mageia.org/en/Mageia_3_Errata
Comment 31 Micael Dias 2013-04-16 00:48:49 UTC
(In reply to comment #28)
> You can pass any of these values on the GRUB command line, but if the value
> you
> are passing is not found in your ACPI BIOS, it will default to the ACPI BIOS
> default, whatever that is. Since "!Windows 2012" is not a valid choice, this
> is
> what's happening to you and we have no idea what the default choice is of
> your
> ACPI BIOS.

Actually, I believe acpi_osi is there to inform the BIOS of which interfaces the OS supports, it doesn't tell the BIOS which OS is running. That's what acpi_os_name does.

You can see I have already disassembled my BIOS (source is attached to this bug report) and if you look at the method "MSOS" you can see that the BIOS first checks if the _OSI variable is accessible, and if so, it checks for the "interface level" to use. Passing "!Windows 2012" to acpi_osi means that the last check ('If (_OSI ("Windows 2012"))') will fail, therefore reporting "Windows 7" (previous successful check) interface level support.

At least this is my understanding of things.
Comment 32 Aaron Lu 2013-04-16 01:01:15 UTC
Hi Dan & Micael,

According to comment #24 and comment #27, it looks the two different models have different problems: on Dan's N56VJ, acpi_video interface works while on Micael's N56VZ, it doesn't. I do not want to mix different problems since it made tracking difficult, so Dan, please file another bug report for N56VJ, thanks.
Comment 33 Micael Dias 2013-04-16 16:13:44 UTC
I just noticed that from 3.9-rc1 forward no Fn key works, and I get this in dmesg:
"asus-nb-wmi: probe of asus-nb-wmi failed with error -5"

I bisected this behaviour to this commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cae06e603339f99334bc6b276e2ac619cf0d476

So I switched to tag v3.8 and applied the patch on comment #21 (once again modified hunk #2 to be able to patch successfuly), but I still don't get any gnome indication when changing the brightness.

I also inserted some debug info on asus-wmi.c on asus_wmi_notify(), and this is what I get when I press the brightness down key:

asus_wmi: wmi notification ff
asus_wmi: wmi: key code: 29
asus_wmi: brightness down, new code = 20

Pressing it again gives me:

asus_wmi: wmi notification ff
asus_wmi: wmi: key code: 28
asus_wmi: brightness down, new code = 20

(values are in hex)

Meaning that the correct key and brightness level is reaching the wmi driver successfully (with acpi_osi="!Windows 2012" only!)
Comment 34 Dan Garton 2013-04-16 22:32:16 UTC
@Aaron: Opened bug 56711
https://bugzilla.kernel.org/show_bug.cgi?id=56711
to track the issue on Asus N56VJ.

Please let me know if you need any specific attachments.
Comment 35 Micael Dias 2013-04-17 00:47:21 UTC
Since it's getting complicated for myself to keep track of every behaviour in every kernel/flags configuration, I decided to recheck everything and put the results here:

http://dl.dropboxusercontent.com/u/87650/asus_n56vz/behaviour.html

Hope it's helpful.
Comment 36 Aaron Lu 2013-04-17 03:00:28 UTC
Hi Micael,

There are some confusing result in the table:
1 there is no code change to video module from v3.8 to v3.8.7, but acpi_video0 starts to work under v3.8.7(both at !win8 mode);
2 there is only one acpi video interface in v3.8.7, while the dmesg showed that two video devices are found as in v3.8:
[   10.459729] ACPI: Video Device [PEGP] (multi-head: yes  rom: yes  post: no)
[   10.464405] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Comment 37 Aaron Lu 2013-04-17 03:20:15 UTC
Hi Micael,

Please try the patch in comment #19, see if manually change backlight works:
# echo 10/20/30/etc. > /sys/class/backlight/acpi_video0/brightness

And no need to add the !windows 2012 command line with that patch, thanks.

BTW, in your table, what's the difference between "Bright. keys" and "Kbd backlight keys"?
Comment 38 Micael Dias 2013-04-17 04:58:01 UTC
(In reply to comment #36)
> Hi Micael,
> 
> There are some confusing result in the table:
> 1 there is no code change to video module from v3.8 to v3.8.7, but
> acpi_video0
> starts to work under v3.8.7(both at !win8 mode);
> 2 there is only one acpi video interface in v3.8.7, while the dmesg showed
> that
> two video devices are found as in v3.8:
> [   10.459729] ACPI: Video Device [PEGP] (multi-head: yes  rom: yes  post:
> no)
> [   10.464405] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

Hi

Indeed it looks confusing, however here's what I get on the machine:

~ ❯❯❯ ls /sys/class/backlight
acpi_video0  intel_backlight
~ ❯❯❯ dmesg | grep "Video Device"
[   13.899832] ACPI: Video Device [PEGP] (multi-head: yes  rom: yes  post: no)
[   13.910054] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
~ ❯❯❯ dmesg | grep "Command line"
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=8d6dec55-ffcb-4696-bdf5-c9307df02b00 ro pcie_aspm=force snd_hda_intel.power_save=1 "acpi_osi=!Windows 2012"

(In reply to comment #37)
> Please try the patch in comment #19, see if manually change backlight works:
> # echo 10/20/30/etc. > /sys/class/backlight/acpi_video0/brightness

I am compiling it right now with your patch attached and all modules. (Previously I was using a trimmed config with only the modules the laptop uses for speed when compiling)
I will post the results as soon as possible.

> BTW, in your table, what's the difference between "Bright. keys" and "Kbd
> backlight keys"?

I should've been more precise. "Bright. keys" are the keys which control screen backlight, while "kbd backlight keys" are the keys that control the keyboard backlight. Keyboard backlight is not important for this thread.
I will change the labels asap, sorry for the confusion.
Comment 39 Micael Dias 2013-04-17 05:23:14 UTC
The patch from comment #19 works great!

I can now see gnome notifications when changing brightness, and I can also change it manually on /sys/class/backlight/acpi_video0.

There's NO /sys/class/backlight/acpi_video1 however, even though dmesg shows 2 "ACPI: Video Device" lines as above.

I still get a "current brightness invalid" error on dmesg though, and the brightness value isn't remembered across reboots.

For curiosity I also tested with the !win8 flag, and it still works, however with much bigger steps each time a brightness key is pressed. (max_brightness is different)
Comment 40 Aaron Lu 2013-04-17 06:55:34 UTC
(In reply to comment #39)
> The patch from comment #19 works great!

The _BCM method firmware provided has two ways to set brightness level:

Method (_BCM, 1, NotSerialized)  // _BCM: Brightness Control Method
{
    Store (One, BCMD)
    Store (GCBL (Arg0), Local0)
    Subtract (0x0A, Local0, LBTN)
    If (BRNC)
    {
        AINT (One, Arg0)  // method 1
    }
    Else
    {
        ^^^LPCB.EC0.STBR () // method 2
    }
}

The BRNC is affected by the patch in comment #19. Method 1 uses intel IGD opration region to set brightness, while method 2 uses EC firmware. So looks like method 1 can work for both win8 mode and !win8 mode.

> 
> I can now see gnome notifications when changing brightness, and I can also
> change it manually on /sys/class/backlight/acpi_video0.

Good, and I think that is due to the setting of BRNC.
Note that the "Notify (LCDD, 0x86)" is only effective when BRNC is set in both UPBL/DWBL functions.

> 
> There's NO /sys/class/backlight/acpi_video1 however, even though dmesg shows
> 2
> "ACPI: Video Device" lines as above.
> 
> I still get a "current brightness invalid" error on dmesg though, and the
> brightness value isn't remembered across reboots.

Please add: acpi.debug_layer=0x10000000 acpi.debug_level=0x4 to kernel command line and attach dmesg. The debug message may reveal something.

> 
> For curiosity I also tested with the !win8 flag, and it still works, however
> with much bigger steps each time a brightness key is pressed. (max_brightness
> is different)
In win8 mode, the firmware will claim support 101 levels(0-100), so that perhaps can explain the bigger steps. I thought _BQC for win8 mode will break, so you have no problem in using hotkey to adjust brightness in win8 mode?
Comment 41 Micael Dias 2013-04-17 14:17:50 UTC
Thanks for the explanation.

(In reply to comment #40)
> > There's NO /sys/class/backlight/acpi_video1 however, even though dmesg
> shows 2
> > "ACPI: Video Device" lines as above.
> > 
> > I still get a "current brightness invalid" error on dmesg though, and the
> > brightness value isn't remembered across reboots.
> 
> Please add: acpi.debug_layer=0x10000000 acpi.debug_level=0x4 to kernel
> command
> line and attach dmesg. The debug message may reveal something.

I am attaching the resulting dmesg in a minute.

> In win8 mode, the firmware will claim support 101 levels(0-100), so that
> perhaps can explain the bigger steps. I thought _BQC for win8 mode will
> break,
> so you have no problem in using hotkey to adjust brightness in win8 mode?

Yes, I have no problem using the brightness keys without the !win8 flag. The brightness can even go down to zero now (turn off the backlight), which I don't think is a problem since I've seen this behaviour in other laptops too.

I have noticed another thing though; the brightness actually seems to be remembered across reboots (even though the "current brightness invalid" message still appears), and it's gdm (I believe) that changes it to max brightness when it starts. If you're interested in a video showing the laptop booting I can make one.
Comment 42 Micael Dias 2013-04-17 14:18:57 UTC
Created attachment 98981 [details]
dmesg from v3.8 with patch from comment #19
Comment 43 Aaron Lu 2013-04-18 06:59:31 UTC
(In reply to comment #41)
> I have noticed another thing though; the brightness actually seems to be
> remembered across reboots (even though the "current brightness invalid"
> message

That message means video driver is setting an invalid brightness level. It would be good to know what's going on, and I'll add more debug statement and please test again then.

BTW, according to the dmesg, the acpi video0 interface is created for GFX0 device, which is the integrated graphics controller(the intel one). And due to the above error, the acpi_video interface for PEGP(the discrete one) is not created. It shouldn't cause any problem as long as you use the integrated graphics controller I think.

> still appears), and it's gdm (I believe) that changes it to max brightness
> when
> it starts. If you're interested in a video showing the laptop booting I can
> make one.

I don't know what GNOME would do regarding this, but for the driver, we actually set the brightness level to max during probe, it is used to quirk broken BIOS. It work like this:
1 get the current brightness level from acpi control method _BQC;
2 set brightness level to max through acpi control method _BCM;
3 get brightness level again from _BQC
4 see if the level got from step 3 matches what we have set in step 2; if no, the _BQC control method provided by the BIOS is broken.
5 for normal working BIOS, set brightness level back to what we have got in step 1.
Comment 44 Aaron Lu 2013-04-18 07:02:10 UTC
Created attachment 99161 [details]
Add some debug print statement in acpi video module

Please apply this patch in addition to the patch in comment #19 on top of v3.8, and boot with acpi.debug_layer=0x10000000 acpi.debug_level=0x4, and attach dmesg, thanks.
Comment 45 Micael Dias 2013-04-18 13:44:14 UTC
Created attachment 99221 [details]
dmesg from v3.8 with patch from comment #19 and comment #44

Here it is.

Again, screen was NOT at max brightness even after
"[   15.422621] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)"

But it turned into max brightness later, which I believe it's when gdm starts.

I also just noticed that the brightness keys don't work properly on gdm login screen. The brightness-down key works fine, but the brightness-up key will only work to go from step 0 (screen off) to 1 (out of 100).

After logging in the keys work reliably again.

If I reboot again the same kernel, the line that reads "ACPI Error: Set level -1539066015 doesn't exist in _BCL list" on this dmesg, becomes "ACPI Error: Set level 1 doesn't exist in _BCL list".
Comment 46 Aaron Lu 2013-04-19 05:08:32 UTC
(In reply to comment #45)
> Here it is.

Thanks.

> 
> Again, screen was NOT at max brightness even after
> "[   15.422621] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post:
> no)"

Note that the time spent from step 1 to 5 may be very small, so you may not be able to feel it.
But OTOH, from the dmesg, BIOS says brightness level is already at 100(which is max level) on boot.

> 
> But it turned into max brightness later, which I believe it's when gdm
> starts.

I've no idea what happened here, since according to BIOS, the initial backlight level is already 100, so theoretically it can't be any higher.

> 
> I also just noticed that the brightness keys don't work properly on gdm login
> screen. The brightness-down key works fine, but the brightness-up key will
> only
> work to go from step 0 (screen off) to 1 (out of 100).
> 
> After logging in the keys work reliably again.
> 
> If I reboot again the same kernel, the line that reads "ACPI Error: Set level
> -1539066015 doesn't exist in _BCL list" on this dmesg, becomes "ACPI Error:
> Set
> level 1 doesn't exist in _BCL list".

Perhaps a _BQC bug, can you please try this git branch:
git://github.com/aaronlu/linux.git acpi_video
It has a fix to detect broken _BQC, and some other enhancements that are not in mainline kernel yet.
And please keep the acpi.debug_layer and acpi.debug_level command line when testing, thanks.
Comment 47 Micael Dias 2013-04-20 03:00:38 UTC
Created attachment 99471 [details]
dmesg from aarons kernel with acpi fixes

Here's the dmesg.

Behaviour is now very weird. No more "invalid brightness" messages but now when booting the screen turned black at the time gdm was supposed to appear. Pressing the brightness up key lit up the monitor. After logging in the screen backlight turned off again. I used the same method as before to bring it back up.

Every time I press a brightness key now, the screen first goes to full brightness for a fraction of a second and then goes to the supposed brightness value.
Comment 48 Micael Dias 2013-04-20 03:31:01 UTC
I have made a video showing the laptop's behaviour with your kernel branch:

http://www.youtube.com/watch?v=s6HxuXwFxzc
Comment 49 Bob Ziuchkovski 2013-04-20 04:55:13 UTC
I have an N56VZ and am affected by this bug as well.  I've discovered from testing that the 3.8.0-19-generic kernel on Ubuntu Raring comes very close to behaving correctly without passing any acpi args to the kernel on boot.  I can correctly adjust the backlight values between 0-100 using /sys/class/backlight/acpi_video0/brightness or 'gnome-control-center screen' (Brightness & Lock panel).  The only thing broken is adjusting via the keyboard fn keys: pressing brightness up/down shows the onscreen brightness display, but I can only go up and down between 2 intervals.  Even then, /sys/class/backlight/acpi_video0/brightness reflects the toggling between the two intervals (values of 85 and 96), and the OSD display looks to be indicating the values correctly in terms of the bar it is drawing.

Anyway, the odd thing is that this nearly-correct behavior appears to be downstream-only (http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.8.0-19.29.diff.gz).  I've tested both the 3.8.0 and 3.8.8 mainline kernels and get no response at all when using the fn keys or 'gnome-control-center screen'.  I haven't tested any of the patches in this bug report, but would be happy to do so.  Right now it looks like Micael has done a bang-up job testing everything.
Comment 50 Bob Ziuchkovski 2013-04-20 05:05:24 UTC
One other relevant piece of info is that my testing on the Ubuntu 3.8.0-19-generic kernel has the value for /sys/class/backlight/acpi_video0/actual_brightness remaining constant (stays at 97), even while I'm changing the brightness value or using gnome-control-center.  The display brightness changes but the value of actual_brightness never does.  I'm guessing that's why the OSD/function keys behave the way they do for me, and why gnome-control-center and echoing values works.
Comment 51 Bob Ziuchkovski 2013-04-20 16:33:00 UTC
Okay, I dug through the Ubuntu patch and it looks like they are doing the same thing as your patch from comment #19.  So I don't really have anything useful to add after all.  :)
Comment 52 Aaron Lu 2013-04-22 04:55:44 UTC
The possible reason is, with some fix patches, the acpi video interface for the discrete graphics card can now be enabled. Do you have two acpi_video inerfaces now? Can you please try to disable the graphics card in the BIOS setup and re-do the test? Thanks.
Comment 53 Aaron Lu 2013-04-22 05:47:13 UTC
Hi Bob,

It would be good if you can also give the code a test:
git://github.com/aaronlu/linux.git acpi_video

Please add: acpi.debug_layer=0x10000000 acpi.debug_level=0x4 to kernel command line when testing.

And please also test with discrete graphics card enabled/disabled, and then attach dmesgs, thanks.
Comment 54 Micael Dias 2013-04-22 14:14:54 UTC
(In reply to comment #52)
> The possible reason is, with some fix patches, the acpi video interface for
> the
> discrete graphics card can now be enabled. Do you have two acpi_video
> inerfaces
> now?

Yes. Only acpi_video1 and intel_backlight do anything though.

> Can you please try to disable the graphics card in the BIOS setup and
> re-do the test? Thanks.

BIOS setup doesn't have such option.
Comment 55 Aaron Lu 2013-04-26 06:47:26 UTC
Sorry for the late reply.

I've added some more debug print in the acpi_video branch, please kindly test again and attach dmesg after you have logged in and pressed hotkey at least once. Thanks.
Comment 56 Micael Dias 2013-04-27 02:57:30 UTC
Created attachment 100021 [details]
 dmesg from aarons kernel with acpi fixes

Here it is. I pressed the brightness-up key more than once, but with large intervals so you can easily separate them in the dmesg and also analyze how the numbers behave.

I noticed something weird that the dmesg numbers confirm. When I'm on very low brightness, if I try to change the brightness, the screen goed to high brightness first for a fraction of a second, and then goes to the desired brightness. This I had already reported, the new thing I noticed is that if I'm on high brightness and try to change the brightness, the opposite happens; the screen first dims to low brightness first, and then goes to the desired brightness.

This behaviour can be confirmed reading the dmesg where the first line that appears after pressing the brightness-up key shows a decreasing number starting on a high value. So there's probably some calculation which is inverted.
Comment 57 Aaron Lu 2013-04-27 03:11:40 UTC
Thanks Micael.

Please add video.use_bios_initial_backlight=0 video.brightness_switch_enabled=0 to kernel command line and see if everything works well.
Comment 58 Aaron Lu 2013-04-27 05:26:45 UTC
I've added even more debug print in the acpi_video branch, please kindly test
again and attach dmesg after you have logged in and pressed hotkey. Thanks.
Comment 59 Micael Dias 2013-04-27 13:50:47 UTC
Created attachment 100081 [details]
dmesg from aarons kernel with acpi fixes

This is without the new flags.
Comment 60 Micael Dias 2013-04-27 13:58:11 UTC
Created attachment 100091 [details]
dmesg from aarons kernel with acpi fixes and video.* flags

This is with the video.* flags.

It still boots up to a unlit screen, and I have to press a brightness key to lit it up. However now it lits up to max brightness (using brightness up key), and I can only get from very low brightness directly to very high brightness without being able to go through all the intermediate levels in between.
Comment 61 Aaron Lu 2013-04-28 02:11:43 UTC
From the log:
set level to 100, _BQC returns 100;
set level t0 0, _BQC returns 100;
set level to 5, _BQC returns 4;
set level to 97, _BQC returns 96;
set level to 9, _BQC returns 8;
...

The refined logic in my tree to detect _BQC logic is:
1 get the current brightness level by _BQC (in your system, it is 100);
2 since 100 is equal to max level, so we choose another level to test as some broken _BQC will always return the original value 100. 0 is chosen to do the test here;
3 _BQC returns 100, making the code thinks it is using index, since _BCL[102] = 0;

And I'm cheated :-(

I will need to refine the logic to detect broken _BQC, perhaps not using edge values.
Comment 62 Micael Dias 2013-04-28 03:14:38 UTC
Yes, as far as I can see on the DSDT table, the _BCL method does something like this when win8 is reported as supported:

http://pastebin.com/dnEkv24E

I got to be honest and say that I have no idea how _BCL is supposed to behave on "normal" laptops as this is the first time I'm being exposed to such low level details, but it looks pretty weird that the 2 first indices of the BRPP array are made "special"...
Comment 63 Micael Dias 2013-04-28 03:18:56 UTC
(In reply to comment #61)
> I will need to refine the logic to detect broken _BQC, perhaps not using edge
> values.

Maybe finding a value!=initial_brightness from the BCL is a better choice in order to be more compatible with other laptops.
Comment 64 Aaron Lu 2013-04-28 04:19:05 UTC
The first two values in _BCL is for when laptop is on AC or on battery, but it's not used by Linux right now, so you can ignore the first two levels of _BCL list.

The acpi_video branch is ready, please give it a test, thanks. No video.* parameters are needed.
Comment 65 Micael Dias 2013-04-28 05:03:26 UTC
Created attachment 100181 [details]
dmesg from aarons kernel with acpi fixes

Here it is. I pressed the brightness-down key 3 times.

It's working fine now, except Xorg/gdm setting the brightness to max when it stars, don't really know why. I think that's outside of this bug's scope though.
Comment 66 Aaron Lu 2013-04-28 05:18:14 UTC
Thanks for your quick response.

I think it doesn't make much sense for acpi video driver to adjust brightness level for systems that have 100 levels, so better use video.brightness_switch_enabled=0. Here is a document patch I've not yet submitted on it:
https://github.com/aaronlu/linux/commit/8d70416a7bf582c7aa0f65d74fb169d580caa21d

And another document patch I think you may be interested:
https://github.com/aaronlu/linux/commit/03c932cb95eb5d38550b7541bf99bc2fea7a4248
Please feel free to give me comments if you have :-)
Comment 67 Micael Dias 2013-04-28 05:46:32 UTC
No problem, thank you for the persistence :)

Indeed using the video.brightness_switch_enabled=0 reduces work done, and works better (nice 5 step intervals, controlled from gnome I believe). Also reduces clutter on dmesg.

Those documentation patches are very useful! Only confusing part was this:

"... The remaining 10 levels are supported levels
that we can change. The range of available brightness levels is from 0 to
max_brightness inclusive."

Which on 1st read left me confused if it's possible to use all levels from 0 to max (in this case 100) or just the supported ones indicated by BCL. However, on second thought I believe you meant that inside the range 0 to max_brightness inclusive, only supported values (indicated by BCL) can be used.

Other than that it's perfect!

Are there plans to merge your acpi branch to master? If so, do you know in which kernel version will this be available?

Thanks a lot for your time spent around this bug. I'm happy I chose an intel machine :)
Comment 68 Aaron Lu 2013-04-28 06:38:01 UTC
(In reply to comment #67)
> Those documentation patches are very useful! Only confusing part was this:
> 
> "... The remaining 10 levels are supported levels
> that we can change. The range of available brightness levels is from 0 to
> max_brightness inclusive."
> 
> Which on 1st read left me confused if it's possible to use all levels from 0
> to
> max (in this case 100) or just the supported ones indicated by BCL. However,
> on
> second thought I believe you meant that inside the range 0 to max_brightness
> inclusive, only supported values (indicated by BCL) can be used.

Please note that acpi video backlight driver will always use index for
brightness, actual_brightness and max_brightness :-)

I think I can update it to:
"
The range of available brightness levels is from 0(mapped to actual levels 0x0A) to max_brightness(9 in this case, mapped to actual levels 0x64) inclusive.
"

And for the 101 levels system, it is actually a 1-1 mapping, i.e. index 0 maps to actual level 0, index 1 maps to actual level 1, etc.

> 
> Other than that it's perfect!
> 
> Are there plans to merge your acpi branch to master? If so, do you know in
> which kernel version will this be available?

3.11 perhaps, they are still going through some internal review process.

> 
> Thanks a lot for your time spent around this bug. I'm happy I chose an intel
> machine :)

I'm glad I can help.

(In reply to comment #63)
> Maybe finding a value!=initial_brightness from the BCL is a better choice in
> order to be more compatible with other laptops.

I think this is a good thing to do, since some broken _BQC will return fixed values and if it happens to equal to br->levels[br->count - 2], then the updated logic is flawed again.

So I updated the code again(sorry! I hope this is the last modify), please give it a test once you are free, thanks a lot!
Comment 69 Micael Dias 2013-04-28 12:43:38 UTC
(In reply to comment #68)
> Please note that acpi video backlight driver will always use index for
> brightness, actual_brightness and max_brightness :-)
> 
> I think I can update it to:
> "
> The range of available brightness levels is from 0(mapped to actual levels
> 0x0A) to max_brightness(9 in this case, mapped to actual levels 0x64)
> inclusive.
> "
> 
> And for the 101 levels system, it is actually a 1-1 mapping, i.e. index 0
> maps
> to actual level 0, index 1 maps to actual level 1, etc.

Ahh, I see. I think it's more readable now. Thanks for the clarification.

> So I updated the code again(sorry! I hope this is the last modify), please
> give
> it a test once you are free, thanks a lot!

No problem! I have a pkgbuild (an arch linux automated build script) that makes rebuilding the kernel with the newest changes and/or patches a small one line command, so don't worry about asking me to test stuff, I will gladly do it as soon as I can :)
Comment 70 Micael Dias 2013-04-28 12:44:38 UTC
Forgot to mention. It still works fine with the newest changes.
Comment 71 Bob Ziuchkovski 2013-04-28 22:48:29 UTC
I finally got a chance to build as well, and the most recent code on your acpi_video branch works perfectly.  Thank you very much!
Comment 72 Ashish 2013-04-30 09:00:25 UTC
is the final patch also working for n56vj?
can someone confirm please.i dont have my notebook with me so just confirming if this fixes the n56VJ bug too or not.
Comment 73 Dan Garton 2013-04-30 11:51:51 UTC
@Ashish, yes it does, see separate bug I did for Aaron at https://bugzilla.kernel.org/show_bug.cgi?id=56711

Hotkeys working fine now on N56VJ.
Comment 74 Aaron Lu 2013-05-06 05:05:22 UTC
Thank you all for your tests.

I did a rebase, now the 2 fix patches are on top of today's linux-next branch of Rafael's tree. It shouldn't cause any problem, but better to be tested again before I submit.
Comment 75 Bob Ziuchkovski 2013-05-06 17:23:25 UTC
I tried to build the rebased branch and while the kernel itself compiles properly, the out-of-kernel nvidia and zfs modules I'm using don't build cleanly.  Unfortunately I'm using ZFS for my root fs, so I won't be able to boot into the rebased version.  I'll try to troubleshoot the build if I get some additional time.
Comment 76 Micael Dias 2013-05-07 00:15:38 UTC
It's still working fine here.
Comment 77 Micael Dias 2013-05-07 00:18:19 UTC
As mentioned in comment #33 I have problems with some other Fn keys though (keyboard backlight and wireless enable/disable), and the asus_nb_wmi error, however I believe I should open another bug report for that.
Comment 78 Aaron Lu 2013-05-07 12:16:39 UTC
Thanks Bob and Micael! I'll start the patch submit process, stay tuned. It may take a while before I sent it outside, the patches needs to go through some internal review process.
Thanks again for your time!
Comment 79 Aaron Lu 2013-05-07 12:17:55 UTC
(In reply to comment #77)
> As mentioned in comment #33 I have problems with some other Fn keys though
> (keyboard backlight and wireless enable/disable), and the asus_nb_wmi error,
> however I believe I should open another bug report for that.

That probably belongs to platform-x86 driver category.
Comment 80 Aaron Lu 2013-06-17 05:58:10 UTC
Sorry for the long delay.

Maintainer doesn't think my fix is necessary, as Matthew submitted a patchset to remove ACPI video backlight interface for win8 systems(your systems all claim support of win8 from the ACPI table). So can you please test that patchset instead?

https://patchwork.kernel.org/patch/2695411/
https://patchwork.kernel.org/patch/2695391/
https://patchwork.kernel.org/patch/2695401/

With the above patches, your system will have only one intel_backlight interface left, which should work.

You will still need the patch in comment #19 to fix the hotkey notification problem(I have submitted today with a different subject), so please apply the four patches and test, for both Asus N56VZ/N56VJ, thanks.
Comment 81 Micael Dias 2013-06-17 16:17:34 UTC
Just tested the mainline tree with the 4 patches and indeed it works.
Comment 82 kholis 2013-06-21 11:43:49 UTC
@Micael

What kernel version did you use to apply those patches? I tried on latest stable kernel v3.9.7 but give me this error:

linux-3.9.7$ patch -p1 --dry-run < 1-3-acpi-video-add-function-to-support-unregister-backlight-interface.patch 
patching file drivers/acpi/video.c
Hunk #3 succeeded at 217 (offset -1 lines).
Hunk #4 succeeded at 817 (offset -71 lines).
Hunk #5 FAILED at 1089.
Hunk #6 succeeded at 970 with fuzz 2 (offset -192 lines).
Hunk #7 succeeded at 1285 (offset -59 lines).
Hunk #8 succeeded at 1820 (offset -57 lines).
1 out of 8 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej
patching file include/acpi/video.h

linux-3.9.7$ patch -p1 --dry-run < 2-3-ACPICA-Add-interface-for-getting-latest-OS-version-requested-via-_OSI.patch 
patching file drivers/acpi/acpica/aclocal.h
Hunk #1 succeeded at 926 (offset -22 lines).
patching file drivers/acpi/acpica/utxface.c
Hunk #1 succeeded at 380 (offset -9 lines).
patching file include/acpi/acpixf.h

linux-3.9.7$ patch -p1 --dry-run < 3-3-i915-Don-t-provide-ACPI-backlight-interface-if-firmware-expects-Windows-8.patch 
patching file drivers/gpu/drm/i915/i915_dma.c
Hunk #1 FAILED at 1661.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_dma.c.rej

linux-3.9.7$ patch -p1 --dry-run < let-OS-handle-brightness-level.patch 
patching file drivers/acpi/video.c
Hunk #1 succeeded at 1458 (offset 16 lines).

Need help. Thanks
Comment 83 Micael Dias 2013-06-21 12:04:37 UTC
(In reply to comment #82)
> @Micael
> 
> What kernel version did you use to apply those patches?

I tried on mainline from Torvald's tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Comment 84 Oleg Kitain 2013-07-20 10:30:54 UTC
Bug confirmed on Dell Inspiron 3521 and kernel 3.8.x. The "acpi_backlight=vendor" workaround works, as does commanding xrandr and echo number > /sys/class/backlight/intel_backlight/brightness, but not echo number > /sysclass/backlight/acpi_backlight/brightness. Is there a patch to that any time soon?
Comment 85 Aaron Lu 2013-07-22 00:51:02 UTC
Yes, the patches are:
https://patchwork.kernel.org/patch/2829342/  (expose OSI version)
https://patchwork.kernel.org/patch/2829344/  (Always call acpi_video_init_brightness() on init)
https://patchwork.kernel.org/patch/2829339/  (No ACPI backlight if firmware expects Windows 8)
https://patchwork.kernel.org/patch/2827878/  (no automatic brightness changes by firmware)

Apply on mainline or v3.10.

Alternatively, they are all in Rafael's acpi-video branch:
http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-video
Comment 86 Aaron Lu 2013-07-22 01:13:54 UTC
Patches in Linus' tree.

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Jul 16 13:08:05 2013 +0800

    ACPI / video: no automatic brightness changes by win8-compatible firmware

commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jul 18 02:08:06 2013 +0200

    ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

commit c04c697cf1fe8f0962ccd3c2392a9b637a5307aa
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date:   Tue Jul 16 17:08:16 2013 +0000

    ACPI / video: Always call acpi_video_init_brightness() on init

commit 242b2287cd7f27521c8b54a4101d569e53e7a0ca
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Jul 2 21:59:10 2013 +0800

    ACPICA: expose OSI version
Comment 87 Micael Dias 2013-07-22 22:26:35 UTC
Just installed 3.11rc2, working great! :)
Comment 88 Aaron Lu 2013-07-23 06:41:12 UTC
Hi Micael,

Thanks for confirming! Unfortunately, James reported a problem:
http://thread.gmane.org/gmane.linux.kernel/1529111
and those commits may get reverted...

I'll keep you guys updated once there is some updates.
Comment 89 Aaron Lu 2013-07-29 01:52:52 UTC
Since the following commit doesn't get reverted:

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Jul 16 13:08:05 2013 +0800

    ACPI / video: no automatic brightness changes by win8-compatible firmware

I suppose you can tweak xorg.conf to specify intel_backlight to work around the probelem?

$ cat /etc/X11/xorg.conf
Section "Device"
        Option     "Backlight"	"intel_backlight"
	Identifier  "Card0"
	Driver      "intel"
	BusID       "PCI:0:2:0"
EndSection
Comment 90 Micael Dias 2013-07-29 15:49:25 UTC
I just installed rc3, and it doesn't work, not even with your xorg.conf solution. All it does is cycle between only 2 levels of brightness, very low and high.

Not even the acpi_osi="!Windows2012" works now.

In /sys/class/backlight I have "acpi_video0", "acpi_video1" and "intel_backlight".

Manually changing acpi_video0 does nothing, acpi_video1 works fine and so does intel_backlight. Using the keyboard to change the backlight makes the acpi_video1 cycle between whatever I set it to and "92". No idea why...

Is there no chance of putting the patches behind a kernel switch or something?
Comment 91 Micael Dias 2013-07-29 15:51:20 UTC
I just noticed that KDE can dim the light correctly by itself when inactive for a period of time. It seems it's just the keyboard keys that are doing weird things...
Comment 92 Aaron Lu 2013-07-30 03:00:15 UTC
Let's see if the hotkey is working as expected first. Please run acpi_listen and then press hotkey multiple times, see if the events are sent out.
Comment 93 Micael Dias 2013-07-30 03:53:52 UTC
Yes, an event is correctly shown for each keypress.
Comment 94 Aaron Lu 2013-07-30 04:12:28 UTC
So the event is correctly sent out and intel_backlight interface is tested to work, what can be the problem... Can you please check your /var/log/Xorg.0.log to make sure the backlight in use is the intel_backlight?
Comment 95 Micael Dias 2013-07-30 14:41:09 UTC
With the option in xorg.conf as suggested in comment #89 I get this:

[   560.598] (**) intel(0): Option "Backlight" "intel_backlight"
[   560.599] (**) intel(0): found backlight control interface intel_backlight (type 'user')


Without the option I get something like this:

(**) intel(0): found backlight control interface acpi_video1 (type 'firmware')


These are the only relevant lines I seem to find in the log file.
Comment 96 Aaron Lu 2013-07-31 02:09:39 UTC
Yes, that means you are using intel_backlight, which is expected. And please always use xorg.conf to specify intel_backlight interface for now.

Can you please check, on each hotkey press, does the intel_backlight's brightness value change?
Comment 97 Micael Dias 2013-07-31 03:47:47 UTC
Yes, it does change.

I just spotted another very weird behaviour again. I'm going to try to explain.

If I always press the brightness up key, it will switch from very low to very bright and then to very low again and so on...

BUT, if I do this sequence:
0) *before starting sequence* --> brightess: 421
1) *press bright-up* -> brightess: 4537
2) *press bright-up* -> brightess: 421
3) *press bright-down* -> brightess: 4441
4) *press bright-up* -> brightess: 536
5) *press bright-down* -> brightess: 4326
6) *press bright-up* -> brightess: 631
7) *press bright-down* -> brightess: 4231
8) *press bright-up* -> brightess: 727
9) *press bright-down* -> brightess: 4135

Before the sequence can be any value. The interesting behaviour is that brightness is going up (and down) little by little usign this sequence. I can also get the values to go the other way if switch the keys in the sequence.
Comment 98 Micael Dias 2013-07-31 03:55:15 UTC
Probably related:
I still have the acpi_video1 device in /sys/class/backlight and it's value seems inverse to the screen's brightness. (low values when screen is bright, high values when screen is dark).

SSH'ing into the laptop shows that when KDE is dimming the display by itself the acpi_video1 brightness value does NOT change but intel_backlight's does.
Comment 99 Aaron Lu 2013-07-31 04:14:20 UTC
(In reply to Micael Dias from comment #98)
> Probably related:
> I still have the acpi_video1 device in /sys/class/backlight and it's value
> seems inverse to the screen's brightness. (low values when screen is bright,
> high values when screen is dark).

It shouldn't matter, since we have told X to use intel_backlight interface.

> 
> SSH'ing into the laptop shows that when KDE is dimming the display by itself
> the acpi_video1 brightness value does NOT change but intel_backlight's does.

This behavior may depend on each interface's implementation.

I'll prepare a debug patch to print out the level values intel_backlight driver receives from user space on each hotkey press, let's see what the problem is.
Comment 100 Aaron Lu 2013-07-31 04:16:23 UTC
Created attachment 107048 [details]
Add debug statement in intel backlight setting function

Apply on top of v3.11-rc3. Then press hotkey to increase/decrease brightness level, check dmesg, see if the value is correct.
Comment 101 Micael Dias 2013-07-31 05:10:18 UTC
This is what I get after pressing the bright-up key 4 times (each key press is separated by a blank line to ease reading):

[   85.054844] i915 0000:00:02.0: intel_panel_set_backlight: level=2, max=255, freq=4882
[   85.054850] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   85.054854] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38
[   85.074422] i915 0000:00:02.0: intel_panel_set_backlight: level=38, max=4882, freq=4882
[   85.074426] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   85.074428] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38
[   85.074569] i915 0000:00:02.0: intel_panel_set_backlight: level=38, max=4882, freq=4882
[   85.074571] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   85.074573] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38

[   88.132252] i915 0000:00:02.0: intel_panel_set_backlight: level=255, max=255, freq=4882
[   88.132261] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   88.132265] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882
[   88.133856] i915 0000:00:02.0: intel_panel_set_backlight: level=4882, max=4882, freq=4882
[   88.133860] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   88.133862] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882
[   88.134020] i915 0000:00:02.0: intel_panel_set_backlight: level=4882, max=4882, freq=4882
[   88.134023] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   88.134024] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882

[   92.236578] i915 0000:00:02.0: intel_panel_set_backlight: level=2, max=255, freq=4882
[   92.236587] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   92.236592] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38
[   92.238038] i915 0000:00:02.0: intel_panel_set_backlight: level=38, max=4882, freq=4882
[   92.238042] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   92.238045] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38
[   92.238219] i915 0000:00:02.0: intel_panel_set_backlight: level=38, max=4882, freq=4882
[   92.238223] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 38
[   92.238225] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=38

[   96.403201] i915 0000:00:02.0: intel_panel_set_backlight: level=255, max=255, freq=4882
[   96.403208] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   96.403212] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882
[   96.405200] i915 0000:00:02.0: intel_panel_set_backlight: level=4882, max=4882, freq=4882
[   96.405205] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   96.405207] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882
[   96.405455] i915 0000:00:02.0: intel_panel_set_backlight: level=4882, max=4882, freq=4882
[   96.405461] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 4882
[   96.405465] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=4882

Full dmesg with more keypresses here: https://dl.dropboxusercontent.com/u/87650/asus_n56vz/dmesg/3.8.11.rc3_debugpatch.txt
Comment 102 Aaron Lu 2013-07-31 05:39:21 UTC
It is weird that the max value keeps changing... it should be a static value of 4882 here. Does the output of "cat /sys/class/backlight/intel_backlight/max_brightness" keep changing too?
Comment 103 Aaron Lu 2013-07-31 05:49:12 UTC
Please also try manually change brightness level through sysfs interface with intel_backlight and see if the max_brightness changes, also pay attention to the kernel log for max value.
Comment 104 Aaron Lu 2013-07-31 05:49:50 UTC
(In reply to Aaron Lu from comment #103)
> Please also try manually change brightness level through sysfs interface
> with intel_backlight and see if the max_brightness changes, also pay
> attention to the kernel log for max value.

The two value should be the same.
Comment 105 Micael Dias 2013-07-31 12:16:43 UTC
/sys/class/backlight/intel_backlight/max_brightness does not change either when using the brightness keys not when manually changing the "brightness" file.

Manually echoing a brightness value to the "brightness" file results in less output in dmesg though.

For example:
> echo 300 > brightness
> cat max_brightness
4882
> dmesg
...
[  275.379090] i915 0000:00:02.0: intel_panel_set_backlight: level=300, max=4882, freq=4882
[  275.379095] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 300
[  275.379097] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=300
Comment 106 Micael Dias 2013-07-31 12:19:51 UTC
The KDE brightness OSD notification also does not appear when pressing the keys, however when using the sequence posted in comment #97 it does show up only when crossing 60%, which is very weird for me.
With 3.8.rc2 the notification worked fine.
Comment 107 Aaron Lu 2013-08-01 05:38:46 UTC
OK, so this is related to hotkey. But I don't see why v3.11-rc2 doesn't have this problem then, can you please re-confirm backlight hotkey works well with v3.11-rc2? Thanks.
Comment 108 Aaron Lu 2013-08-01 08:07:35 UTC
I suppose all the above tests are done without the acpi_osi="!Windows2012" cmdline?
Comment 109 Sam 2013-08-01 21:49:40 UTC
Hi Aaron,
I can confirm that it works perfectly on 3.11-rc2 without any specific cmdline (ie without acpi_osi="!Windows2012")
Comment 110 Sam 2013-08-01 21:58:06 UTC
I also tried with acpi_osi="!Windows2012" but I didn't notice any difference
Comment 111 Sam 2013-08-01 22:04:50 UTC
(In reply to Aaron Lu from comment #7)
> Hi Micael and Jos,
> 
> Thanks for the report!
> 
> Is it possible for you to test from which kernel does the bug appear? Jos
> mentioned 3.4 works, what about 3.5/6/7?

3.4.55 : partially working (gnome brightness notification doesn't show so I guess that it is the BIOS that controls backlight)
3.10.0 : not working
3.9.4 : not working
3.2.0-41-generic to 3.2.0-50-generic (from ubuntu) : working (I haven't tried vanilla 3.2)


Maybe is has something to do with asus_wmi kernel module...?
Comment 112 Micael Dias 2013-08-02 01:18:49 UTC
(In reply to Aaron Lu from comment #107)
> OK, so this is related to hotkey. But I don't see why v3.11-rc2 doesn't have
> this problem then, can you please re-confirm backlight hotkey works well
> with v3.11-rc2? Thanks.

Just re-installed rc2. Working fine without acpi_osi flag.

(In reply to Aaron Lu from comment #108)
> I suppose all the above tests are done without the acpi_osi="!Windows2012"
> cmdline?

Yes, all tests have been done without acpi_osi flag.

I also applied your debug patch on top rc2 to see if anything weird (like the max value changing) was happening, but other than brightness being set 3 times for each keypress, there's nothing wrong.
Comment 113 Aaron Lu 2013-08-02 01:25:21 UTC
Can you please apply the commit 8e5c2b776ae4c35f54547c017e0a943429f5748a (the revert patch sent out by Rafael) on top of v3.11-rc2? Let's rule out any potential problems introduced in i915 driver code in rc3 first, thanks.
Comment 114 Micael Dias 2013-08-02 02:25:38 UTC
Applying 8e5c2b776ae4c35f54547c017e0a943429f5748a to rc2 makes it not work correctly again. Behaves like rc3.
Comment 115 Aaron Lu 2013-08-02 02:32:24 UTC
(In reply to Micael Dias from comment #114)
> Applying 8e5c2b776ae4c35f54547c017e0a943429f5748a to rc2 makes it not work
> correctly again. Behaves like rc3.

With intel_backlight specified in xorg.conf? And manually change brightness works while Fn key doesn't, right?
Comment 116 Aaron Lu 2013-08-02 03:03:00 UTC
Good news, I've found a ASUS laptop that has the same problem. The problem is, on hotkey press, an ASLE interrupt would occur before notification is sent out and the interrupt caused a wrong backlight level getting set. I'm looking into this issue and will get you updated once I have some conclusion.
Comment 117 Micael Dias 2013-08-02 03:11:46 UTC
(In reply to Aaron Lu from comment #115)
> (In reply to Micael Dias from comment #114)
> > Applying 8e5c2b776ae4c35f54547c017e0a943429f5748a to rc2 makes it not work
> > correctly again. Behaves like rc3.
> 
> With intel_backlight specified in xorg.conf? And manually change brightness
> works while Fn key doesn't, right?

That's right.

(In reply to Aaron Lu from comment #116)
> Good news, I've found a ASUS laptop that has the same problem. The problem
> is, on hotkey press, an ASLE interrupt would occur before notification is
> sent out and the interrupt caused a wrong backlight level getting set. I'm
> looking into this issue and will get you updated once I have some conclusion.

That's already good news! Thanks.
Comment 118 Aaron Lu 2013-08-02 05:35:32 UTC
Sigh... After some time's confusion, it turned out, the video module's brightness_switch_enabled parameter is enabled by default so that on each hotkey, it will cause ACPI video module to adjust the brightness level too. And since the interface is broken, we are setting a wrong value(but the set works). Later when X decides to adjust brightness level, it will see the wrong value and then does the adjustment.

The quick fix is to add the video.brightness_switch_enabled=0 to kernel cmdline. I'll see if we can make this param default to 0.

Thanks a lot for all your tests, Micael and Sam.
Comment 119 Micael Dias 2013-08-02 12:32:39 UTC
I confirm that  video.brightness_switch_enabled=0 works for me.
It's kind of weird that it sets the brightness 7 times when pressing the key (according to dmesg and your patch) but as long as it works fine I'm happy with it :)
Comment 120 Aaron Lu 2013-08-02 13:22:35 UTC
(In reply to Micael Dias from comment #119)
> I confirm that  video.brightness_switch_enabled=0 works for me.
> It's kind of weird that it sets the brightness 7 times when pressing the key

With different brightness levels or exactly the same level? Mine has several times too, but with slightly different levels, it seems user space want to do some smooth setting.
Comment 121 Micael Dias 2013-08-02 13:54:28 UTC
Testing now:

1) current brightness: 1954
2) *press bright-up*
3) dmesg: intel_panel_set_backlight: 1954
dmesg: intel_panel_set_backlight: 1954
dmesg: intel_panel_set_backlight: 1954
dmesg: intel_panel_set_backlight: 1954
dmesg: intel_panel_set_backlight: 2442
dmesg: intel_panel_set_backlight: 2442
dmesg: intel_panel_set_backlight: 2442

So, there's no smoothness, only several kind of weird commands. But the actual result is fine. KDE shows notifications for brightness changes and changes in 10% increments.

When KDE changes the brightness on its own (inactivity or waking from it) I also get many (not a fixed number) commands per brightness change on dmesg instead of just one. Seems to range from 3 to 7.
Manually echoing a value to intel_brightness only generates one command, so this is probably something the userspace is doing and is out of scope of this bug report.
Comment 122 Aaron Lu 2013-08-02 14:02:25 UTC
Yes, I think so. I use GNOME, so the behavior is different with KDE.
Comment 123 Micael Dias 2013-08-02 14:05:59 UTC
Just tested GNOME to be sure.
Pressing a brightness key only generates 2 commands. The first sets the brightness to the old value and the next sets brightness to new value. So it's fine I think.
Comment 124 Micael Dias 2013-08-02 15:10:11 UTC
I just tested without the xorg.conf option and it still works fine, even though the log says "found backlight control interface acpi_video1 (type 'firmware')"
Comment 125 Aaron Lu 2013-08-02 15:20:36 UTC
I remember hotkey doesn't work with ACPI video interface on this system due to broken _BQC, things have changed?
Comment 126 Micael Dias 2013-08-02 15:38:16 UTC
No, things have not changed.

3.10.x -> doesn't work
3.10.x + acpi_osi="!Windows 2012" -> doesn't work (just noticed that, since I've been using 3.11)
3.10.x + video.brightness_switch_enabled=0 -> doesn't work
3.11.rc2 + revert patch + video.brightness_switch_enabled=0 -> works

This tests have been done right now without the xorg.conf option. However it seems that KDM boots to a unlit screen (brightness=0), and the brightness keys don't work there. I ssh'ed into the machine and turn the brightness up to be able to see anything.
Comment 127 Micael Dias 2013-08-02 15:38:54 UTC
To clarity, the brightness keys work fine again after logging in.
Comment 128 Micael Dias 2013-08-02 15:46:47 UTC
Doesn't work so fine after all, just noticed dmesg.
It is using "255" as max value again, and setting and inverse value again before setting the correct value.

For example:

*press brightness key*
set brightness: 250
set brightness: 5
*press brightness key*
set brightness: 240
set brightness: 15
*press brightness key*
set brightness: 230
set brightness: 25
...

Which to the user LOOKS ok, but isn't. I noticed it by mere chance when the screen dimmed to turn off it flickered. So, back to using xorg.conf option.
Comment 129 Felipe Contreras 2013-08-02 18:49:16 UTC
I created a new bug report (bug 60682) with a blacklist patch, many machines are affected by this.

This is the list I've gathered so far:

* ASUS Zenbook Prime UX31A
* ASUS N56VZ
* Lenovo ThinkPad L430
* Lenovo ThinkPad T430s
* Lenovo ThinkPad T530
* Lenovo ThinkPad W530
* Lenovo ThinkPad X1 Carbon
* Lenovo ThinkPad X230
* Lenovo ThinkPad Edge E330

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

Add a comment in bug 60682.
Comment 130 Felipe Contreras 2013-08-02 19:18:19 UTC
(In reply to Micael Dias from comment #128)
> Doesn't work so fine after all, just noticed dmesg.
> It is using "255" as max value again, and setting and inverse value again
> before setting the correct value.

I have the same issue in my ASUS UX31A.

I'm attaching a patch to test something, and force some values that make it work correctly. This is on top of v3.11-rc3.
Comment 131 Felipe Contreras 2013-08-02 19:19:42 UTC
Created attachment 107085 [details]
Test quirk

Apply this on top of v3.11-rc3, then attach the dmesg output:

% dmesg | grep 'acpi: video: quirk'
Comment 132 Felipe Contreras 2013-08-02 19:31:47 UTC
Created attachment 107086 [details]
Test quirk (v2)

Last one was buggy.

Apply this on top of v3.11-rc3, then attach the dmesg output:

% dmesg | grep 'acpi: video: quirk'
Comment 133 Felipe Contreras 2013-08-02 19:47:37 UTC
This is the actual patch I proposed to LKML:

http://mid.gmane.org/1375472229-1563-1-git-send-email-felipe.contreras@gmail.com

But the above test would help see if indeed the issue is the same.
Comment 134 Micael Dias 2013-08-02 21:45:30 UTC
@Felipe Contreras
Aaron found an asus laptop with the same issue and was able to track down what the problem is.
If you use a special option in xorg.conf (see comment #89) and a kernel flag (see comment #118) you should have the backlight keys working properly again. At least for me it worked.
Comment 135 Felipe Contreras 2013-08-02 22:01:24 UTC
(In reply to Micael Dias from comment #134)
> @Felipe Contreras
> Aaron found an asus laptop with the same issue and was able to track down
> what the problem is.

No, he found *one* problem, there are more.

> If you use a special option in xorg.conf (see comment #89) and a kernel flag
> (see comment #118) you should have the backlight keys working properly
> again. At least for me it worked.

I can get the keys working in many ways, but they should work out-of-the-box without any hacks. Most users are not reading this bugzilla and won't change the boot command.

For now the only reliable way to fix the problems out-of-the-box for everyone is the above patch.
Comment 136 Micael Dias 2013-08-02 22:20:41 UTC
I agree, but I don't think it's Aaron's intention to just leave users to use these workarounds.
But anyway, the faster some fix appears, the better. We can always fix it properly later if needed.
Comment 137 Felipe Contreras 2013-08-03 01:36:38 UTC
(In reply to Micael Dias from comment #136)
> I agree, but I don't think it's Aaron's intention to just leave users to use
> these workarounds.
> But anyway, the faster some fix appears, the better. We can always fix it
> properly later if needed.

The patch in bug 60682 fixes the issue, does it not? Basically applying the patch is the same as booting with acpi_osi="!Windows 2012" for the blacklisted machines.
Comment 138 Aaron Lu 2013-08-03 02:09:48 UTC
(In reply to Felipe Contreras from comment #135)
> (In reply to Micael Dias from comment #134)
> > @Felipe Contreras
> > Aaron found an asus laptop with the same issue and was able to track down
> > what the problem is.
> 
> No, he found *one* problem, there are more.

I suppose you didn't bother reading the whole comments history here, or you wouldn't say this. The ASUS NV56J/Z system here has the following problems:
1 _BQC is broken, this is solved in comment #64 and #65;
2 The hotkey doesn't generate events, this fix patch is in Linus' tree now.

Then we decide to use intel_backlight for Win8 systems, so I didn't submit the patch mentioned in comment #64 and #65. In v3.11-rc2 everything works. After the revert, rc3 doesn't work and we have tracked down the problem to be video module still getting in the way by handling hotkey event by default.

So tell me, what problems I have missed?

Your attitude made me feel that you know everything better than anyone else and we are intentionally screwing the user. This is unfair.
Comment 139 Micael Dias 2013-08-03 02:52:07 UTC
(In reply to Felipe Contreras from comment #137)
> The patch in bug 60682 fixes the issue, does it not? Basically applying the
> patch is the same as booting with acpi_osi="!Windows 2012" for the
> blacklisted machines.

I decided to test your patch. With it the brightness changes, however the keypresses don't seem to get to userspace, and I lose every other hotkey functionality (including vol-up vol-down hotkeys), so I'm back at what I had on comment #5 minus the acpi_listen output (I don't get any now with your patch) and minus the other Fn keys.
Comment 140 Micael Dias 2013-08-03 02:59:04 UTC
Actually some random Fn keys appear to work, like the sleep key and the screen-off key. Not sure which others work, but that's irrelevant for this bug report.

With rc3 + video.brightness_switch_enabled=0 everything seems to work fine.
Comment 141 Felipe Contreras 2013-08-03 20:54:15 UTC
(In reply to Micael Dias from comment #139)

> I decided to test your patch. With it the brightness changes, however the
> keypresses don't seem to get to userspace, and I lose every other hotkey
> functionality (including vol-up vol-down hotkeys), so I'm back at what I had
> on comment #5 minus the acpi_listen output (I don't get any now with your
> patch) and minus the other Fn keys.

That is with v3.11-rc3 + plus my patch, and nothing in the boot arguments?

> With rc3 + video.brightness_switch_enabled=0 everything seems to work fine.

If v3.11-rc3 works without my patch, it should work with my patch. I think you are missing something.
Comment 142 Felipe Contreras 2013-08-03 21:06:00 UTC
(In reply to Aaron Lu from comment #138)
> (In reply to Felipe Contreras from comment #135)
> > (In reply to Micael Dias from comment #134)
> > > @Felipe Contreras
> > > Aaron found an asus laptop with the same issue and was able to track down
> > > what the problem is.
> > 
> > No, he found *one* problem, there are more.
> 
> I suppose you didn't bother reading the whole comments history here, or you
> wouldn't say this.

I did read it.

> The ASUS NV56J/Z system here has the following problems:
> 1 _BQC is broken, this is solved in comment #64 and #65;

It is broken only in win8, presumably, as the same happens in my machine.

I provided a much simpler patch:
http://article.gmane.org/gmane.linux.acpi.devel/62717

However, that is not relevant in win8 mode disabled, which is what my patch tries to do.

Your patch (or mine) won't be in v3.11 either way, so v3.11 won't be fixed.

> 2 The hotkey doesn't generate events, this fix patch is in Linus' tree now.

Good. What is that patch?

I cannot find it in:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log?qt=author&q=Aaron+Lu

> Then we decide to use intel_backlight for Win8 systems, so I didn't submit
> the patch mentioned in comment #64 and #65.

That is very self-centered.

Regardless of what "you" decide, people still use acpi_backlight, not everyone has Intel video cards, and people can still do Option "Backlight"	"acpi_backlight".

Unless acpi_backlight is removed, fixes should be sent.

> In v3.11-rc2 everything works.

Except that level 0 turns the screen now. Which I consider a regression, and other people too.

> After the revert, rc3 doesn't work and we have tracked down the problem to
> be video module still getting in the way by handling hotkey event by default.

Good, where is that patch?

> So tell me, what problems I have missed?

I didn't say you missed any problem, I objected to Micael Dias's wording that you found *the* problem.

That being said, if all the problems are found, is everything going to work correctly in v3.11?

> Your attitude made me feel that you know everything better than anyone else
> and we are intentionally screwing the user. This is unfair.

My attitude is irrelevant, we need to get the fixes to the users.
Comment 143 Felipe Contreras 2013-08-03 21:07:56 UTC
(In reply to Felipe Contreras from comment #142)

> > So tell me, what problems I have missed?
> 
> I didn't say you missed any problem, I objected to Micael Dias's wording
> that you found *the* problem.
> 
> That being said, if all the problems are found, is everything going to work
> correctly in v3.11?

Also, have you considered that this patch will probably be reverted for v3.11?

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
Comment 144 Aaron Lu 2013-08-04 01:12:00 UTC
(In reply to Felipe Contreras from comment #143)
> (In reply to Felipe Contreras from comment #142)
> 
> > > So tell me, what problems I have missed?
> > 
> > I didn't say you missed any problem, I objected to Micael Dias's wording
> > that you found *the* problem.
> > 
> > That being said, if all the problems are found, is everything going to work
> > correctly in v3.11?
> 
> Also, have you considered that this patch will probably be reverted for
> v3.11?
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8

No, it will not be reverted. Rafael has the idea of reverting the commit totally due to you have said it caused the problem of booting into a black screen. I've just explained to him that problem is due to the broken _BQC, not this commit. So I don't think this commit will be reverted.

BTW, this is the commit that make firmware emit notifications on hotkey press.
Comment 145 Micael Dias 2013-08-04 01:32:30 UTC
(In reply to Felipe Contreras from comment #141)
> (In reply to Micael Dias from comment #139)
> 
> > I decided to test your patch. With it the brightness changes, however the
> > keypresses don't seem to get to userspace, and I lose every other hotkey
> > functionality (including vol-up vol-down hotkeys), so I'm back at what I
> had
> > on comment #5 minus the acpi_listen output (I don't get any now with your
> > patch) and minus the other Fn keys.
> 
> That is with v3.11-rc3 + plus my patch, and nothing in the boot arguments?

Yes.

> > With rc3 + video.brightness_switch_enabled=0 everything seems to work fine.
> 
> If v3.11-rc3 works without my patch, it should work with my patch. I think
> you are missing something.

Your patch makes the BIOS behave as if the test for "Windows 2012" string is reported as "not suported" by the kernel, which apparently makes BIOS not send any hotkey notifications in my case and handle brightness by itself.

If you open the first attachment in this bug report (the DSDT table) you'll see that my BIOS behaves very differently with and without "Windows 2012" support reported by linux.
Comment 146 Aaron Lu 2013-08-04 01:36:47 UTC
(In reply to Felipe Contreras from comment #142)
> (In reply to Aaron Lu from comment #138)
> > (In reply to Felipe Contreras from comment #135)
> > > (In reply to Micael Dias from comment #134)
> > > > @Felipe Contreras
> > > > Aaron found an asus laptop with the same issue and was able to track
> down
> > > > what the problem is.
> > > 
> > > No, he found *one* problem, there are more.
> > 
> > I suppose you didn't bother reading the whole comments history here, or you
> > wouldn't say this.
> 
> I did read it.

I doubt.

> 
> > The ASUS NV56J/Z system here has the following problems:
> > 1 _BQC is broken, this is solved in comment #64 and #65;
> 
> It is broken only in win8, presumably, as the same happens in my machine.
> 
> I provided a much simpler patch:
> http://article.gmane.org/gmane.linux.acpi.devel/62717
> 
> However, that is not relevant in win8 mode disabled, which is what my patch
> tries to do.
> 
> Your patch (or mine) won't be in v3.11 either way, so v3.11 won't be fixed.

Yes it will, I think Rafael plans to queue that quirk patch. But that isn't a problem if user is using intel_backlight.

> 
> > 2 The hotkey doesn't generate events, this fix patch is in Linus' tree now.
> 
> Good. What is that patch?
> 
> I cannot find it in:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> log?qt=author&q=Aaron+Lu

I've told you in my last comment.

> 
> > Then we decide to use intel_backlight for Win8 systems, so I didn't submit
> > the patch mentioned in comment #64 and #65.
> 
> That is very self-centered.

It's not. The maintainers(Matthew and Rafael) have decided to use intel_backlight, and I followed.

> 
> Regardless of what "you" decide, people still use acpi_backlight, not
> everyone has Intel video cards, and people can still do Option "Backlight"
> "acpi_backlight".

Obviously the quirk patch solved a problem for systems that are all Win8 systems and for all Win8 systems intel_backlight is the choice.

> 
> Unless acpi_backlight is removed, fixes should be sent.

The interface is removed by i915 driver, fix is irrelevant.

> 
> > In v3.11-rc2 everything works.
> 
> Except that level 0 turns the screen now. Which I consider a regression, and
> other people too.

You either get this "regression", or you lose hotkey event. Which one you like?

> 
> > After the revert, rc3 doesn't work and we have tracked down the problem to
> > be video module still getting in the way by handling hotkey event by
> default.
> 
> Good, where is that patch?

Since you have read every commit here, I suppose you know what the problem is. And I'm proposing making this change with the maintainer. Check the mailing list on this topic:[PATCH 5/5] acpi_video: Don't handle ACPI brightness notifications by default

> 
> > So tell me, what problems I have missed?
> 
> I didn't say you missed any problem, I objected to Micael Dias's wording
> that you found *the* problem.

I find it. See comment #118. And that's the problem I and Micael are talking about and you just don't bother reading the history and claim something else.

> 
> That being said, if all the problems are found, is everything going to work
> correctly in v3.11?

Yes, see comment #140.

> 
> > Your attitude made me feel that you know everything better than anyone else
> > and we are intentionally screwing the user. This is unfair.
> 
> My attitude is irrelevant, we need to get the fixes to the users.

Right, I agree.
Comment 147 Micael Dias 2013-08-04 01:39:36 UTC
(In reply to Felipe Contreras from comment #142)
> Except that level 0 turns the screen now. Which I consider a regression, and
> other people too.

To be honest your patch doesn't solve this either. It just gives up taking control over the Fn keys (at least in my case).
With or without "Windows 2012" support, if .../intel_backlight/brightness is zero the screen will turn off. I don't know what the standard behaviour should be, but it kind of makes sense that "zero backlight" is .. zero backlight.
Comment 148 Micael Dias 2013-08-04 01:45:14 UTC
(In reply to Aaron Lu from comment #146)
> It's not. The maintainers(Matthew and Rafael) have decided to use
> intel_backlight, and I followed.
> 
> > 
> > Regardless of what "you" decide, people still use acpi_backlight, not
> > everyone has Intel video cards, and people can still do Option "Backlight"
> > "acpi_backlight".
> 
> Obviously the quirk patch solved a problem for systems that are all Win8
> systems and for all Win8 systems intel_backlight is the choice.
> 
> > 
> > Unless acpi_backlight is removed, fixes should be sent.
> 
> The interface is removed by i915 driver, fix is irrelevant.

Does this mean the option in xorg.conf will be unnecessary?
Comment 149 Aaron Lu 2013-08-04 03:51:32 UTC
(In reply to Micael Dias from comment #148)
> (In reply to Aaron Lu from comment #146)
> > It's not. The maintainers(Matthew and Rafael) have decided to use
> > intel_backlight, and I followed.
> > 
> > > 
> > > Regardless of what "you" decide, people still use acpi_backlight, not
> > > everyone has Intel video cards, and people can still do Option
> "Backlight"
> > > "acpi_backlight".
> > 
> > Obviously the quirk patch solved a problem for systems that are all Win8
> > systems and for all Win8 systems intel_backlight is the choice.
> > 
> > > 
> > > Unless acpi_backlight is removed, fixes should be sent.
> > 
> > The interface is removed by i915 driver, fix is irrelevant.
> 
> Does this mean the option in xorg.conf will be unnecessary?

We did that in rc2, but due to bugs in intel_backlight driver, it is reverted, so the acpi_video interface is not removed now.

In the meantime, maintainer decides to take the patch to solve the broken _BQC problem now, so the acpi_video interface should also work in v3.11 timeline. I'll let you know when that patch enters Linus' tree. Then you can decide to use intel_backlight with xorg.conf + video.brightness_switch_enabled=0 or acpi_video without any cmdline options.
Comment 150 Felipe Contreras 2013-08-04 07:06:42 UTC
(In reply to Aaron Lu from comment #144)
> No, it will not be reverted. Rafael has the idea of reverting the commit
> totally due to you have said it caused the problem of booting into a black
> screen.

Rafael is thinking of doing it, which is precisely what I said; there's a possibility that would happen.

And it does cause the black screen problem: I revert that commit; no black screen, I keep it; black screen. Do you believe me, or do you need me to record a video showing that's the case?

> I've just explained to him that problem is due to the broken _BQC,
> not this commit. So I don't think this commit will be reverted.
> 
> BTW, this is the commit that make firmware emit notifications on hotkey
> press.

It does more than that on this machine. Either my patch is applied (or yours, which seem less likely), or the commit is reverted. Those seem to be the only options.
Comment 151 Felipe Contreras 2013-08-04 07:16:16 UTC
(In reply to Micael Dias from comment #145)

> If you open the first attachment in this bug report (the DSDT table) you'll
> see that my BIOS behaves very differently with and without "Windows 2012"
> support reported by linux.

So does my machine, yet the events reach user-space.

How about trying this on top of my patch?

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -238,7 +238,7 @@ static void acpi_video_caps_check(void)
 
 bool acpi_video_backlight_quirks(void)
 {
-       return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
+       return true;
 }
 EXPORT_SYMBOL(acpi_video_backlight_quirks);
Comment 152 Felipe Contreras 2013-08-04 07:50:44 UTC
(In reply to Aaron Lu from comment #146)
> (In reply to Felipe Contreras from comment #142)

> > Your patch (or mine) won't be in v3.11 either way, so v3.11 won't be fixed.
> 
> Yes it will, I think Rafael plans to queue that quirk patch. But that isn't
> a problem if user is using intel_backlight.

By default intel_backlight is not used, the *vast* majority of users use the default.

> > > 2 The hotkey doesn't generate events, this fix patch is in Linus' tree
> now.
> > 
> > Good. What is that patch?
> > 
> > I cannot find it in:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> > log?qt=author&q=Aaron+Lu
> 
> I've told you in my last comment.

No, you didn't.

If you are talking about efaa14c (ACPI / video: no automatic brightness changes by win8-compatible firmware), even that has the possibility of being reverted, as you have said; Rafael is thinking about that.

> > > Then we decide to use intel_backlight for Win8 systems, so I didn't
> submit
> > > the patch mentioned in comment #64 and #65.
> > 
> > That is very self-centered.
> 
> It's not. The maintainers(Matthew and Rafael) have decided to use
> intel_backlight, and I followed.

It seems to be you are not following this simple train of thought.

The acpi_backlight is provided by the kernel, it must be fixed. It's totally and completely irrelevant what the Intel graphics driver does, not everybody is going to use it, not everybody has an Intel card; if there's a bug in acpi_backlight code, it gets fixed. That's it.

> > Regardless of what "you" decide, people still use acpi_backlight, not
> > everyone has Intel video cards, and people can still do Option "Backlight"
> > "acpi_backlight".
> 
> Obviously the quirk patch solved a problem for systems that are all Win8
> systems and for all Win8 systems intel_backlight is the choice.

Not for v3.11, and maybe not v3.12, or even v3.13.

> > Unless acpi_backlight is removed, fixes should be sent.
> 
> The interface is removed by i915 driver, fix is irrelevant.

No it's not.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/video.c

See? The code is still there. People use code that is there.

And what about people that don't use i915, or do you only care about people that use Intel? What about people that configure their X driver like Option "Backlight" "acpi_backlight"? Screw them?

> > > In v3.11-rc2 everything works.
> > 
> > Except that level 0 turns the screen now. Which I consider a regression,
> and
> > other people too.
> 
> You either get this "regression", or you lose hotkey event. Which one you
> like?

False dichotomy fallacy.

I have two branches in which I have both a level 0 that works, and I get events, one with intel_backlight, and one with acpi_backlight. I you can't even *see* how that is possible, I don't think there's much point in discussing with you.

Either way, v3.11 will not "just work", probably neither will v3.12.

> > > After the revert, rc3 doesn't work and we have tracked down the problem
> to
> > > be video module still getting in the way by handling hotkey event by
> default.
> > 
> > Good, where is that patch?
> 
> Since you have read every commit here, I suppose you know what the problem
> is. And I'm proposing making this change with the maintainer. Check the
> mailing list on this topic:[PATCH 5/5] acpi_video: Don't handle ACPI
> brightness notifications by default

This is what Rafael said about that:

"Well, it will have to stay that way in 3.11 I'm afraid, unless we have a fix or a workaround that is *guaranteed* not to introduce any new issues on any systems."

So, yeah, it won't just work on v3.11.

> > > So tell me, what problems I have missed?
> > 
> > I didn't say you missed any problem, I objected to Micael Dias's wording
> > that you found *the* problem.
> 
> I find it. See comment #118. And that's the problem I and Micael are talking
> about and you just don't bother reading the history and claim something else.

Micael said in comment #128 that it didn't work so great after all, so he will need my patch. Who is not reading the history now?

> > That being said, if all the problems are found, is everything going to work
> > correctly in v3.11?
> 
> Yes, see comment #140.

video.brightness_switch_enabled will be 1 in v3.11, so the answer is NO.

And either way, I'm not so sure Micael is in the same page as us, I'll explain in another comment.

> > > Your attitude made me feel that you know everything better than anyone
> else
> > > and we are intentionally screwing the user. This is unfair.
> > 
> > My attitude is irrelevant, we need to get the fixes to the users.
> 
> Right, I agree.

Good, let's do that.
Comment 153 Felipe Contreras 2013-08-04 08:10:44 UTC
(In reply to Micael Dias from comment #147)
> (In reply to Felipe Contreras from comment #142)
> > Except that level 0 turns the screen now. Which I consider a regression,
> and
> > other people too.
> 
> To be honest your patch doesn't solve this either. It just gives up taking
> control over the Fn keys (at least in my case).
> With or without "Windows 2012" support, if .../intel_backlight/brightness is
> zero the screen will turn off. I don't know what the standard behaviour
> should be, but it kind of makes sense that "zero backlight" is .. zero
> backlight.

Wait, you are using the intel_backlight? By default the intel X driver uses acpi_backlight, have you been trying my patch with a modified xorg.conf?

To be sure, this is what you should try:

A)

You mentioned in comment #128 something about wrong inverse values and screen off at boot, for that you need to try my patch in comment #132, which has a good chance of getting in v3.11, so... You're welcome.

If your machine is similar to mine, if you boot with acpi_osi="!Windows 2012", you won't see this issue you mentioned.

You should test my patch on top of v3.11-rc3, you should always test the latest tag, unless otherwise specified, with no other patch, without the modified xorg.conf, and without boot arguments.

The user-space notification might not work, but setting the levels would work, and it shouldn't boot to a black screen. If you want the user-space notification to work, you might then try with video.brightness_switch_enabled=0.

B)

The patch in bug #60682 is a separate patch, you said you tried without boot arguments, but did you try it with the default backlight driver? Don't modify it.

If the user-space notifications don't work, then try video.brightness_switch_enabled=0.
Comment 154 Felipe Contreras 2013-08-04 08:14:06 UTC
(In reply to Felipe Contreras from comment #153)
> A)
> 
> You mentioned in comment #128 something about wrong inverse values and
> screen off at boot, for that you need to try my patch in comment #132, which
> has a good chance of getting in v3.11, so... You're welcome.

Actually, the real patch is the one in comment #133:

http://article.gmane.org/gmane.linux.acpi.devel/62717

But the one in comment #128 would help make sure the issue is similar to mine, I don't know why you aren't cooperating to figure this out and posting the dmesg with that patch.
Comment 155 Aaron Lu 2013-08-04 11:02:19 UTC
(In reply to Felipe Contreras from comment #150)
> (In reply to Aaron Lu from comment #144)
> > No, it will not be reverted. Rafael has the idea of reverting the commit
> > totally due to you have said it caused the problem of booting into a black
> > screen.
> 
> Rafael is thinking of doing it, which is precisely what I said; there's a
> possibility that would happen.

Because he thought that commit caused the problem of booting into a black screen as you told him, while I think the problem of booting into a black screen is due to broken _BQC, not the said commit here. So as long as we explain clearly to him, I don't think he will revert it. Unless you insist that commit should be reverted, because it caused the black screen problem.

> 
> And it does cause the black screen problem: I revert that commit; no black
> screen, I keep it; black screen. Do you believe me, or do you need me to
> record a video showing that's the case?

I believe you, but I think the bug lies in broken _BQC, not that commit. Do you agree or not?

> 
> > I've just explained to him that problem is due to the broken _BQC,
> > not this commit. So I don't think this commit will be reverted.
> > 
> > BTW, this is the commit that make firmware emit notifications on hotkey
> > press.
> 
> It does more than that on this machine. Either my patch is applied (or
> yours, which seem less likely), or the commit is reverted. Those seem to be
> the only options.

Yes, either your patch or mine(I don't care that much which one gets applied as long as the problem is solved) can solve the problem, and I think this is the right way to solve it, instead of revering that commit.
Comment 156 Felipe Contreras 2013-08-04 11:20:22 UTC
(In reply to Aaron Lu from comment #155)
> (In reply to Felipe Contreras from comment #150)
> > (In reply to Aaron Lu from comment #144)
> > > No, it will not be reverted. Rafael has the idea of reverting the commit
> > > totally due to you have said it caused the problem of booting into a
> black
> > > screen.
> > 
> > Rafael is thinking of doing it, which is precisely what I said; there's a
> > possibility that would happen.
> 
> Because he thought that commit caused the problem of booting into a black
> screen as you told him,

For v3.11 it doesn't matter what causes it, what matters is what fixes it, and how it can be done in time. Reverting efaa14c fixes it, and can be done in time, so that's one possibility being considered.

> while I think the problem of booting into a black
> screen is due to broken _BQC, not the said commit here.

This is a matter of semantics. Maybe the broken _BQC "causes" it, but efaa14c triggered it.

> So as long as we
> explain clearly to him, I don't think he will revert it. Unless you insist
> that commit should be reverted, because it caused the black screen problem.

It does "cause" it, or trigger it, or whatever you want to call it. And reverting that patch fixes it.

> > And it does cause the black screen problem: I revert that commit; no black
> > screen, I keep it; black screen. Do you believe me, or do you need me to
> > record a video showing that's the case?
> 
> I believe you, but I think the bug lies in broken _BQC, not that commit. Do
> you agree or not?

I don't think you understand the very simple fact that a bug can have multiple "causes".

But I'm so interested in the causes, I'm interested on the fixes, and there's many ways to fix this bug, but only a couple can be done for v3.11.

> > > I've just explained to him that problem is due to the broken _BQC,
> > > not this commit. So I don't think this commit will be reverted.
> > > 
> > > BTW, this is the commit that make firmware emit notifications on hotkey
> > > press.
> > 
> > It does more than that on this machine. Either my patch is applied (or
> > yours, which seem less likely), or the commit is reverted. Those seem to be
> > the only options.
> 
> Yes, either your patch or mine(I don't care that much which one gets applied
> as long as the problem is solved) can solve the problem, and I think this is
> the right way to solve it, instead of revering that commit.

I agree it is *probably* the best approach for v3.11. Hopefully efaa14c didn't cause (trigger) any other bugs that were hidden before, it's a gamble. The safest thing would be to revert efaa14c, and apply it again on v3.12.

But that's not my decision to make; I'm simply providing the facts; there are *two* changes that fix the problem in this machine.
Comment 157 Aaron Lu 2013-08-04 11:43:42 UTC
(In reply to Felipe Contreras from comment #152)
> (In reply to Aaron Lu from comment #146)
> > (In reply to Felipe Contreras from comment #142)
> 
> > > > 2 The hotkey doesn't generate events, this fix patch is in Linus' tree
> now.
> > > 
> > > Good. What is that patch?
> > > 
> > > I cannot find it in:
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> > > log?qt=author&q=Aaron+Lu
> > 
> > I've told you in my last comment.
> 
> No, you didn't.

Yes I have, see comment #144.

> 
> It seems to be you are not following this simple train of thought.
> 
> The acpi_backlight is provided by the kernel, it must be fixed. It's totally
> and completely irrelevant what the Intel graphics driver does, not everybody
> is going to use it, not everybody has an Intel card; if there's a bug in
> acpi_backlight code, it gets fixed. That's it.

Yes I'm fixing acpi_video problems all the time.

> 
> > > Regardless of what "you" decide, people still use acpi_backlight, not
> > > everyone has Intel video cards, and people can still do Option
> "Backlight"
> > > "acpi_backlight".
> > 
> > Obviously the quirk patch solved a problem for systems that are all Win8
> > systems and for all Win8 systems intel_backlight is the choice.
> 
> Not for v3.11, and maybe not v3.12, or even v3.13.

So we are now solving problems for acpi_video, is there a problem?

> 
> And what about people that don't use i915, or do you only care about people
> that use Intel? What about people that configure their X driver like Option
> "Backlight" "acpi_backlight"? Screw them?

I don't know how backlight is supposed to work on those systems, so I'll not do anything about it to avoid making mistakes or people like you will say "your patch screwed user".

> 
> > > > In v3.11-rc2 everything works.
> > > 
> > > Except that level 0 turns the screen now. Which I consider a regression,
> and
> > > other people too.
> > 
> > You either get this "regression", or you lose hotkey event. Which one you
> > like?
> 
> False dichotomy fallacy.
> 
> I have two branches in which I have both a level 0 that works, and I get
> events, one with intel_backlight, and one with acpi_backlight. I you can't
> even *see* how that is possible, I don't think there's much point in
> discussing with you.

I don't even know what do you mean by level 0 works. But I agree with you, just
 stop discussing with me.

> > > > So tell me, what problems I have missed?
> > > 
> > > I didn't say you missed any problem, I objected to Micael Dias's wording
> > > that you found *the* problem.
> > 
> > I find it. See comment #118. And that's the problem I and Micael are
> talking
> > about and you just don't bother reading the history and claim something
> else.
> 
> Micael said in comment #128 that it didn't work so great after all, so he
> will need my patch. Who is not reading the history now?

You didn't read the history before, and you don't bother read it now.
For comment #128, Micael means using rc3 with acpi_video interface doesn't work(which is expected, since the broken _BQC patch is not applied yet). Hell, why do I even care explain this to you when all the things are written there???
Comment 158 Felipe Contreras 2013-08-04 13:58:46 UTC
(In reply to Aaron Lu from comment #157)
> (In reply to Felipe Contreras from comment #152)

> > It seems to be you are not following this simple train of thought.
> > 
> > The acpi_backlight is provided by the kernel, it must be fixed. It's
> totally
> > and completely irrelevant what the Intel graphics driver does, not
> everybody
> > is going to use it, not everybody has an Intel card; if there's a bug in
> > acpi_backlight code, it gets fixed. That's it.
> 
> Yes I'm fixing acpi_video problems all the time.

Apparently right until the moment Intel decided to use intel_backlight instead. At that point you decided to not send fixes, even if you already had the patch.

> > > > Regardless of what "you" decide, people still use acpi_backlight, not
> > > > everyone has Intel video cards, and people can still do Option
> "Backlight"
> > > > "acpi_backlight".
> > > 
> > > Obviously the quirk patch solved a problem for systems that are all Win8
> > > systems and for all Win8 systems intel_backlight is the choice.
> > 
> > Not for v3.11, and maybe not v3.12, or even v3.13.
> 
> So we are now solving problems for acpi_video, is there a problem?

NOW. You should have sent the fix when you found the solution and we wouldn't be having this discussion.

> > And what about people that don't use i915, or do you only care about people
> > that use Intel? What about people that configure their X driver like Option
> > "Backlight" "acpi_backlight"? Screw them?
> 
> I don't know how backlight is supposed to work on those systems, so I'll not
> do anything about it to avoid making mistakes or people like you will say
> "your patch screwed user".

Oh, please.

Above you said acpi_backlight has to be fixed regardless, and now you say you'll not do anything about it?

Fortunately the fix is sent:

http://article.gmane.org/gmane.linux.acpi.devel/62717

Anyway, I actually believe you don't even understand what it is I'm saying, so I'm not going to discuss that point.

> > > You either get this "regression", or you lose hotkey event. Which one you
> > > like?
> > 
> > False dichotomy fallacy.
> > 
> > I have two branches in which I have both a level 0 that works, and I get
> > events, one with intel_backlight, and one with acpi_backlight. I you can't
> > even *see* how that is possible, I don't think there's much point in
> > discussing with you.
> 
> I don't even know what do you mean by level 0 works. But I agree with you,
> just
>  stop discussing with me.

By "work" I mean not turn the screen off. You said I had to pick one, I pick   none, and I have the code for that.

> > > > > So tell me, what problems I have missed?
> > > > 
> > > > I didn't say you missed any problem, I objected to Micael Dias's
> wording
> > > > that you found *the* problem.
> > > 
> > > I find it. See comment #118. And that's the problem I and Micael are
> talking
> > > about and you just don't bother reading the history and claim something
> else.
> > 
> > Micael said in comment #128 that it didn't work so great after all, so he
> > will need my patch. Who is not reading the history now?
> 
> You didn't read the history before, and you don't bother read it now.
> For comment #128, Micael means using rc3 with acpi_video interface doesn't
> work(which is expected, since the broken _BQC patch is not applied yet).

Yes, that's exactly what I said; he will need my patch.

http://article.gmane.org/gmane.linux.acpi.devel/62717

You didn't send that patch, did you?

So no, things wouldn't have "just worked" in v3.11, not without my involvement.

All I'm saying is that comment #134 is not exactly correct. I don't see what's the big problem with that.
Comment 159 Dan Garton 2013-08-04 14:40:38 UTC
Created attachment 107090 [details]
attachment-17108-0.html

I haven't been tracking the discussion closely ... Just a reminder from
myself as a user that the work you devs are doing is gratefully
acknowledged,
even though the details of the problem are somewhat difficult to resolve!

Sterling work, guys, keep it up .....

On 4 August 2013 14:58, <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=52951
>
> --- Comment #158 from Felipe Contreras <felipe.contreras@gmail.com> ---
> (In reply to Aaron Lu from comment #157)
> > (In reply to Felipe Contreras from comment #152)
>
> > > It seems to be you are not following this simple train of thought.
> > >
> > > The acpi_backlight is provided by the kernel, it must be fixed. It's
> totally
> > > and completely irrelevant what the Intel graphics driver does, not
> everybody
> > > is going to use it, not everybody has an Intel card; if there's a bug
> in
> > > acpi_backlight code, it gets fixed. That's it.
> >
> > Yes I'm fixing acpi_video problems all the time.
>
> Apparently right until the moment Intel decided to use intel_backlight
> instead.
> At that point you decided to not send fixes, even if you already had the
> patch.
>
> > > > > Regardless of what "you" decide, people still use acpi_backlight,
> not
> > > > > everyone has Intel video cards, and people can still do Option
> "Backlight"
> > > > > "acpi_backlight".
> > > >
> > > > Obviously the quirk patch solved a problem for systems that are all
> Win8
> > > > systems and for all Win8 systems intel_backlight is the choice.
> > >
> > > Not for v3.11, and maybe not v3.12, or even v3.13.
> >
> > So we are now solving problems for acpi_video, is there a problem?
>
> NOW. You should have sent the fix when you found the solution and we
> wouldn't
> be having this discussion.
>
> > > And what about people that don't use i915, or do you only care about
> people
> > > that use Intel? What about people that configure their X driver like
> Option
> > > "Backlight" "acpi_backlight"? Screw them?
> >
> > I don't know how backlight is supposed to work on those systems, so I'll
> not
> > do anything about it to avoid making mistakes or people like you will say
> > "your patch screwed user".
>
> Oh, please.
>
> Above you said acpi_backlight has to be fixed regardless, and now you say
> you'll not do anything about it?
>
> Fortunately the fix is sent:
>
> http://article.gmane.org/gmane.linux.acpi.devel/62717
>
> Anyway, I actually believe you don't even understand what it is I'm
> saying, so
> I'm not going to discuss that point.
>
> > > > You either get this "regression", or you lose hotkey event. Which
> one you
> > > > like?
> > >
> > > False dichotomy fallacy.
> > >
> > > I have two branches in which I have both a level 0 that works, and I
> get
> > > events, one with intel_backlight, and one with acpi_backlight. I you
> can't
> > > even *see* how that is possible, I don't think there's much point in
> > > discussing with you.
> >
> > I don't even know what do you mean by level 0 works. But I agree with
> you,
> > just
> >  stop discussing with me.
>
> By "work" I mean not turn the screen off. You said I had to pick one, I
> pick
> none, and I have the code for that.
>
> > > > > > So tell me, what problems I have missed?
> > > > >
> > > > > I didn't say you missed any problem, I objected to Micael Dias's
> wording
> > > > > that you found *the* problem.
> > > >
> > > > I find it. See comment #118. And that's the problem I and Micael are
> talking
> > > > about and you just don't bother reading the history and claim
> something else.
> > >
> > > Micael said in comment #128 that it didn't work so great after all, so
> he
> > > will need my patch. Who is not reading the history now?
> >
> > You didn't read the history before, and you don't bother read it now.
> > For comment #128, Micael means using rc3 with acpi_video interface
> doesn't
> > work(which is expected, since the broken _BQC patch is not applied yet).
>
> Yes, that's exactly what I said; he will need my patch.
>
> http://article.gmane.org/gmane.linux.acpi.devel/62717
>
> You didn't send that patch, did you?
>
> So no, things wouldn't have "just worked" in v3.11, not without my
> involvement.
>
> All I'm saying is that comment #134 is not exactly correct. I don't see
> what's
> the big problem with that.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 160 Aaron Lu 2013-08-05 01:20:27 UTC
(In reply to Felipe Contreras from comment #158)
> (In reply to Aaron Lu from comment #157)
> > (In reply to Felipe Contreras from comment #152)
> 
> > > It seems to be you are not following this simple train of thought.
> > > 
> > > The acpi_backlight is provided by the kernel, it must be fixed. It's
> totally
> > > and completely irrelevant what the Intel graphics driver does, not
> everybody
> > > is going to use it, not everybody has an Intel card; if there's a bug in
> > > acpi_backlight code, it gets fixed. That's it.
> > 
> > Yes I'm fixing acpi_video problems all the time.
> 
> Apparently right until the moment Intel decided to use intel_backlight
> instead. At that point you decided to not send fixes, even if you already
> had the patch.

I think you have checked my commits in kernel tree and you just don't notice all those bug fix commits I have submitted for video module? And also check the reviewed-by tag.

For this commit alone, we decided to use intel_backlight for this system and we shipped that code in rc2, then revert it in rc3. So I didn't submit the patch in a week's time and you claim I do not send patches for ACPI video module and I do not want bug fixed and I just care about Intel systems. I guess attack other people make you feel high?

> 
> > > > > Regardless of what "you" decide, people still use acpi_backlight, not
> > > > > everyone has Intel video cards, and people can still do Option
> "Backlight"
> > > > > "acpi_backlight".
> > > > 
> > > > Obviously the quirk patch solved a problem for systems that are all
> Win8
> > > > systems and for all Win8 systems intel_backlight is the choice.
> > > 
> > > Not for v3.11, and maybe not v3.12, or even v3.13.
> > 
> > So we are now solving problems for acpi_video, is there a problem?
> 
> NOW. You should have sent the fix when you found the solution and we
> wouldn't be having this discussion.

Yes now, after the patches to remove ACPI video interface gets removed in rc3. It's a long time?

> 
> > > And what about people that don't use i915, or do you only care about
> people
> > > that use Intel? What about people that configure their X driver like
> Option
> > > "Backlight" "acpi_backlight"? Screw them?
> > 
> > I don't know how backlight is supposed to work on those systems, so I'll
> not
> > do anything about it to avoid making mistakes or people like you will say
> > "your patch screwed user".
> 
> Oh, please.
> 
> Above you said acpi_backlight has to be fixed regardless, and now you say
> you'll not do anything about it?

Oh, please.

You can't understand my words. For ACPI video backlight, I'll always send patches to fix problems as long as the interface will be used in the system. For systems I don't know how backlight is supposed to work, I'll not since I don't know how things are supposed to work and don't have access to those systems to verify.
Comment 161 Felipe Contreras 2013-08-05 01:42:20 UTC
(In reply to Aaron Lu from comment #160)
> (In reply to Felipe Contreras from comment #158)

> > Apparently right until the moment Intel decided to use intel_backlight
> > instead. At that point you decided to not send fixes, even if you already
> > had the patch.
> 
> I think you have checked my commits in kernel tree and you just don't notice
> all those bug fix commits I have submitted for video module? And also check
> the reviewed-by tag.
> 
> For this commit alone, we decided to use intel_backlight for this system and
> we shipped that code in rc2, then revert it in rc3. So I didn't submit the
> patch in a week's time and you claim I do not send patches for ACPI video
> module and I do not want bug fixed and I just care about Intel systems. I
> guess attack other people make you feel high?

I did not say that. Again, I believe you don't even understand what I'm saying. You read the words, you don't understand the meaning.

I did not claim you don't send patches for the ACPI video module, I claimed you didn't send *THAT* patch, which is true.

It's OK to prioritize other things, but it's not OK to hold on to a fix you already have. It doesn't matter if you, or your employer will use that patch, other people will.

> > Oh, please.
> > 
> > Above you said acpi_backlight has to be fixed regardless, and now you say
> > you'll not do anything about it?
> 
> Oh, please.
> 
> You can't understand my words. For ACPI video backlight, I'll always send
> patches to fix problems as long as the interface will be used in the system.

You mean Intel systems? That's the only thing you care about?

> For systems I don't know how backlight is supposed to work, I'll not since I
> don't know how things are supposed to work and don't have access to those
> systems to verify.

Maybe you just lack imagination.

% echo 10 > /sys/class/backlight/acpi_video0/brightness

Does the same regardless of what video card the system has.
Comment 162 Aaron Lu 2013-08-05 01:50:20 UTC
(In reply to Felipe Contreras from comment #161)
> (In reply to Aaron Lu from comment #160)
> > (In reply to Felipe Contreras from comment #158)
> 
> > > Apparently right until the moment Intel decided to use intel_backlight
> > > instead. At that point you decided to not send fixes, even if you already
> > > had the patch.
> > 
> > I think you have checked my commits in kernel tree and you just don't
> notice
> > all those bug fix commits I have submitted for video module? And also check
> > the reviewed-by tag.
> > 
> > For this commit alone, we decided to use intel_backlight for this system
> and
> > we shipped that code in rc2, then revert it in rc3. So I didn't submit the
> > patch in a week's time and you claim I do not send patches for ACPI video
> > module and I do not want bug fixed and I just care about Intel systems. I
> > guess attack other people make you feel high?
> 
> I did not say that. Again, I believe you don't even understand what I'm
> saying. You read the words, you don't understand the meaning.

I agree I have difficulty in understanding your words. You are the only one I've difficulty in understanding and communicating with till now.

> 
> I did not claim you don't send patches for the ACPI video module, I claimed
> you didn't send *THAT* patch, which is true.

In a week's time, yes.

> 
> It's OK to prioritize other things, but it's not OK to hold on to a fix you
> already have. It doesn't matter if you, or your employer will use that
> patch, other people will.

Again, in a week's time, yes.

> 
> > > Oh, please.
> > > 
> > > Above you said acpi_backlight has to be fixed regardless, and now you say
> > > you'll not do anything about it?
> > 
> > Oh, please.
> > 
> > You can't understand my words. For ACPI video backlight, I'll always send
> > patches to fix problems as long as the interface will be used in the
> system.
> 
> You mean Intel systems? That's the only thing you care about?

You do know that ACPI doesn't differentiate vendors, do you?

> 
> > For systems I don't know how backlight is supposed to work, I'll not since
> I
> > don't know how things are supposed to work and don't have access to those
> > systems to verify.
> 
> Maybe you just lack imagination.
> 
> % echo 10 > /sys/class/backlight/acpi_video0/brightness
> 
> Does the same regardless of what video card the system has.

As I said, ACPI doesn't differentiate vendors. Why this has anything to do with imagination? And do you know there are systems that do not use ACPI video's backlight interface for backlight control? I mean those systems(maybe they are not in PC form factor).
Comment 163 Felipe Contreras 2013-08-05 02:19:53 UTC
(In reply to Aaron Lu from comment #162)

> > > You can't understand my words. For ACPI video backlight, I'll always send
> > > patches to fix problems as long as the interface will be used in the
> system.
> > 
> > You mean Intel systems? That's the only thing you care about?
> 
> You do know that ACPI doesn't differentiate vendors, do you?

That's exactly my point, so it's irrelevant if there's a i915 or not, and if "the interface will be used in the system". The patch is still needed.
Comment 164 Aaron Lu 2013-08-05 05:34:58 UTC
(In reply to Felipe Contreras from comment #163)
> (In reply to Aaron Lu from comment #162)
> 
> > > > You can't understand my words. For ACPI video backlight, I'll always
> send
> > > > patches to fix problems as long as the interface will be used in the
> system.
> > > 
> > > You mean Intel systems? That's the only thing you care about?
> > 
> > You do know that ACPI doesn't differentiate vendors, do you?
> 
> That's exactly my point, so it's irrelevant if there's a i915 or not, and if
> "the interface will be used in the system". The patch is still needed.

The quirk patch fix a broken firmware problem on an Intel system with i915 card, and in that system the ACPI video interface will be removed by i915 driver in rc2. For the user of this system, with or without that patch the backlight will work out of box. And due to the interface is removed, the user has no chance of using it in any way.

With rc3, since the patch that removes acpi_video interface is reverted, this quirk patch will be needed.
Comment 165 Felipe Contreras 2013-08-05 14:18:02 UTC
(In reply to Aaron Lu from comment #164)

> The quirk patch fix a broken firmware problem on an Intel system with i915
> card

The patch is not for this system, it's for this system *and* many many many more.
Comment 166 Micael Dias 2013-08-05 16:58:41 UTC
I just tried "Test quirk (v2)" on top of rc4, without xorg.conf option, and it doesn't work properly.

The brightness-down key works, but the brightness up key also reduces brightness some levels an then goes back up to the level it was when I first pressed it.

For example:

brightness (from acpi_video1): 48
*press bright up*
brightness: 46
*press bright up*
brightness: 44
*press bright up*
brightness: 42
*press bright up*
brightness: 40
*press bright up*
brightness: 48
... // loop
Comment 167 Felipe Contreras 2013-08-05 17:48:43 UTC
(In reply to Micael Dias from comment #166)

> The brightness-down key works, but the brightness up key also reduces
> brightness some levels an then goes back up to the level it was when I first
> pressed it.

Then your machine must be different than mine. How about the dmesg?

Also, as I explained in comment #154, this is the actual patch that will be applied on v3.11:

http://article.gmane.org/gmane.linux.acpi.devel/62717

That's for A), there's also B); did you try the patch in bug #60682 without xorg modifications?
Comment 168 Sam 2013-08-05 20:12:23 UTC
Hi everybody,

it is a bit hard to follow you and I am getting a bit lost ;-)
Ok, let me try to summarize :


1- The initial bug report was filled against ASUS N56VZ.
Maybe we should all share the model we are using because it seems we have different issues/behavior.
Mine is :
dmesg | grep DMI
[    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.215 11/02/2012


2- Felipe, in bug #60682 you say: "If your machine works correctly with acpi_osi="!Windows 2012""
Well, I did some tests with and without this boot parameter against 3.10, but there was no change at all.
Do you still want us to test this patch?


3- Aaron, in 3.11-rc3 (and 3.11-rc4), video.brightness_switch_enabled=0, and only this parameter (no xorg.conf change) didnt gave me very good results ( sorry :-( ):
- it gives me a black screen at boot (i guess it means "no backlight when lightdm starts").
- It is then impossible to switch on the screen with the keyboard.
- Fortunately I have a xbacklight-set 100 that runs when opening my gnome session. It gave me back my backlight back, and then the Fn brightness keys were working but in a strange behavior (screen was a bit flashing when changing backlight and it hurt my eyes :-)).
Should I try both video.brightness_switch_enabled=0 AND xorg.conf tweak?


4- Without video.brightness_switch_enabled=0, on 3.11-rc3 (and 3.11-r4): no backlight at boot and then "full on / full off" backlight


5- Felipe, I tried the patch http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4 and it seems to work well.
The behavior is the same with and without video.brightness_switch_enabled=0 : brightness is on at boot and Fn brightness keys are working well. Min brightness makes screen goes off (or backlight goes off) but personally I don't care


6- I also tried this on top of 3.11-rc3 as advised by Rafael J. Wysocki on lkml:
Make acpi_video_backlight_quirks() in drivers/acpi/video_detect.c return always false: 
- the Fn+x keys are not working anymore (remember that they didn't work in 3.10 nor 3.9)
- At least the backlight remains on at boot.
- Gnome brightness settings do not work anymore. Neither do xbacklight.
- Writing to /sys/class/backlight/intel_backlight/brightness works
- With this setting, video.brightness_switch_enabled=0 has no effect at all


--> In the end, best results are currently achieved with that patch on top of 3.11rc4 : http://article.gmane.org/gmane.linux.acpi.devel/62717
The patch seems a bit empiric, but hey, it's working...
Do you confirm it will be included in 3.11?


I know you guys are having some disagreements, but let's kiss and make it up... or maybe no kiss and just make it up?
No, I'm kidding: as Dan Garton, thank you all for your time, your help and your patience !
We all want the same in the end: a working and stable system...
So I don't know what is the best answer to this bug (maybe 3.11rc2 was?), but I can do more tests and I will always respect your work, both of you :-)


Regards,
Sam
Comment 169 Felipe Contreras 2013-08-05 20:50:54 UTC
(In reply to Sam from comment #168)

> 2- Felipe, in bug #60682 you say: "If your machine works correctly with
> acpi_osi="!Windows 2012""
> Well, I did some tests with and without this boot parameter against 3.10,
> but there was no change at all.

I find that hard to believe. If I'm correct, in v3.10 backlight control shouldn't work at all, but with that option it should.

Are you certain that this command:

echo 20 > /sys/class/backlight/acpi_video0/brightness

Works the same with or without acpi_osi="!Windows 2012"?

> 5- Felipe, I tried the patch
> http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4 and
> it seems to work well.
> The behavior is the same with and without video.brightness_switch_enabled=0
> : brightness is on at boot and Fn brightness keys are working well. Min
> brightness makes screen goes off (or backlight goes off) but personally I
> don't care

That's weird. If you had problems with the Fn keys, then you should need video.brightness_switch_enabled=0.

> 6- I also tried this on top of 3.11-rc3 as advised by Rafael J. Wysocki on
> lkml:
> Make acpi_video_backlight_quirks() in drivers/acpi/video_detect.c return
> always false: 
> - the Fn+x keys are not working anymore (remember that they didn't work in
> 3.10 nor 3.9)
> - At least the backlight remains on at boot.
> - Gnome brightness settings do not work anymore. Neither do xbacklight.
> - Writing to /sys/class/backlight/intel_backlight/brightness works
> - With this setting, video.brightness_switch_enabled=0 has no effect at all

You should try /sys/class/backlight/acpi_backlight/brightness, that's what the UI would use.

You should have exactly the same behavior as in v3.10.

> --> In the end, best results are currently achieved with that patch on top
> of 3.11rc4 : http://article.gmane.org/gmane.linux.acpi.devel/62717
> The patch seems a bit empiric, but hey, it's working...

It is not, there's a very good reason for that, and it's explained in the patch :)

> Do you confirm it will be included in 3.11?

I appears so.
Comment 170 Micael Dias 2013-08-05 21:09:45 UTC
(In reply to Felipe Contreras from comment #167)
> (In reply to Micael Dias from comment #166)
> 
> > The brightness-down key works, but the brightness up key also reduces
> > brightness some levels an then goes back up to the level it was when I
> first
> > pressed it.
> 
> Then your machine must be different than mine. How about the dmesg?
> 
> Also, as I explained in comment #154, this is the actual patch that will be
> applied on v3.11:
> 
> http://article.gmane.org/gmane.linux.acpi.devel/62717
> 
> That's for A), there's also B); did you try the patch in bug #60682 without
> xorg modifications?

Sorry for the incomplete info, I kind of lost track of what I'm supposed to test with all the discussion.

interesting dmesg parts:
apci: video: quirk: test 18 = 1
apci: video: quirk: test 23 = 2
apci: video: quirk: test 1 = 100
apci: video: quirk: test 2 = 100

I believe I tested the patch in bug #60682 WITH xorg option. To be honest I think it's irrelevant because all that does (afaict) is force acpi_osi="!Windows 2012" which we already know it's supposed to "work" (backlight is controlled but doesn't send notifications).
If you still think I should re-test that please say so.

I will now try the patch you say will go into 3.11 and will report as soon as possible.
Thanks.
Comment 171 Sam 2013-08-05 21:31:40 UTC
(In reply to Felipe Contreras from comment #169)
> (In reply to Sam from comment #168)
> 
> > 2- Felipe, in bug #60682 you say: "If your machine works correctly with
> > acpi_osi="!Windows 2012""
> > Well, I did some tests with and without this boot parameter against 3.10,
> > but there was no change at all.
> 
> I find that hard to believe. If I'm correct, in v3.10 backlight control
> shouldn't work at all, but with that option it should.
> 
> Are you certain that this command:
> 
> echo 20 > /sys/class/backlight/acpi_video0/brightness
> 
> Works the same with or without acpi_osi="!Windows 2012"?

done as root on 3.11rc4 + http://article.gmane.org/gmane.linux.acpi.devel/62717 :

echo 20 > /sys/class/backlight/acpi_video0/brightness 
-su: echo: write error: Invalid argument

cat /sys/class/backlight/acpi_video0/brightness
10
(it remains at 10 whatever my brightness is)
 
on the other hand:
cat /sys/class/backlight/intel_backlight/brightness 
4882
(this value is max brightness, and decreases when I decrease brightness)



> > 5- Felipe, I tried the patch
> > http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4
> and
> > it seems to work well.
> > The behavior is the same with and without video.brightness_switch_enabled=0
> > : brightness is on at boot and Fn brightness keys are working well. Min
> > brightness makes screen goes off (or backlight goes off) but personally I
> > don't care
> 
> That's weird. If you had problems with the Fn keys, then you should need
> video.brightness_switch_enabled=0.

uname -r
3.11.0-rc4

dmesg:
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11-rc4 root=/dev/sda4 ro quiet splash vt.handoff=7

and I confirm it is working like a charm...
Comment 172 Micael Dias 2013-08-05 21:41:56 UTC
The patch from http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of rc4 doesn't work for me.

Pressing the backlight keys I get the behaviour described in comment #97
Comment 173 Micael Dias 2013-08-05 21:43:54 UTC
I forgot to mention that the patch also made KDM boot into a zero blacklight screen, however I could turn it on using the backlight keys, which suggests ACPI is still controlling the backlight, otherwise I should (from previous experience) only be able to change brightness after logging in.
Comment 174 Micael Dias 2013-08-05 21:48:43 UTC
Also booting the same patched kernel with video.brightness_switch_enabled=0 gives me a zero backlight screen again, however this time I have to ssh into the laptop to turn on the light.

After logging in the backlight almost works good. Same as comment #128.
Comment 175 Micael Dias 2013-08-05 21:52:00 UTC
And finally, patched kernel + video.brightness_switch_enabled=0 + xorg.conf option works fine. Same as comment #119.
Comment 176 Felipe Contreras 2013-08-05 21:53:21 UTC
(In reply to Micael Dias from comment #170)

> Sorry for the incomplete info, I kind of lost track of what I'm supposed to
> test with all the discussion.
> 
> interesting dmesg parts:
> apci: video: quirk: test 18 = 1
> apci: video: quirk: test 23 = 2
> apci: video: quirk: test 1 = 100
> apci: video: quirk: test 2 = 100

Do you have two acpi_backlight interfaces?

> I believe I tested the patch in bug #60682 WITH xorg option. To be honest I
> think it's irrelevant because all that does (afaict) is force
> acpi_osi="!Windows 2012" which we already know it's supposed to "work"
> (backlight is controlled but doesn't send notifications).

Just test it.
Comment 177 Micael Dias 2013-08-05 21:56:58 UTC
(In reply to Felipe Contreras from comment #176)
> Do you have two acpi_backlight interfaces?

Yes, I have acpi_video0, acpi_video1 and intel_backlight in /sys/class/backlight.

> Just test it.

Ok, I will test it later today.
Comment 178 Felipe Contreras 2013-08-05 21:58:27 UTC
(In reply to Sam from comment #171)
> (In reply to Felipe Contreras from comment #169)
> > (In reply to Sam from comment #168)
> > 
> > > 2- Felipe, in bug #60682 you say: "If your machine works correctly with
> > > acpi_osi="!Windows 2012""
> > > Well, I did some tests with and without this boot parameter against 3.10,
> > > but there was no change at all.
> > 
> > I find that hard to believe. If I'm correct, in v3.10 backlight control
> > shouldn't work at all, but with that option it should.
> > 
> > Are you certain that this command:
> > 
> > echo 20 > /sys/class/backlight/acpi_video0/brightness
> > 
> > Works the same with or without acpi_osi="!Windows 2012"?
> 
> done as root on 3.11rc4 +
> http://article.gmane.org/gmane.linux.acpi.devel/62717 :
> 
> echo 20 > /sys/class/backlight/acpi_video0/brightness 
> -su: echo: write error: Invalid argument
> 
> cat /sys/class/backlight/acpi_video0/brightness
> 10
> (it remains at 10 whatever my brightness is)

Is that with "!Windows 2012"? Do you have an acpi_video1?

> > > 5- Felipe, I tried the patch
> > > http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4
> and
> > > it seems to work well.
> > > The behavior is the same with and without
> video.brightness_switch_enabled=0
> > > : brightness is on at boot and Fn brightness keys are working well. Min
> > > brightness makes screen goes off (or backlight goes off) but personally I
> > > don't care
> > 
> > That's weird. If you had problems with the Fn keys, then you should need
> > video.brightness_switch_enabled=0.
> 
> uname -r
> 3.11.0-rc4
> 
> dmesg:
> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11-rc4
> root=/dev/sda4 ro quiet splash vt.handoff=7
> 
> and I confirm it is working like a charm...

All right, then v3.11 will probably work fine :)

BTW. Is the level restored properly on boot, or is it always 100%?
Comment 179 Felipe Contreras 2013-08-05 22:02:24 UTC
(In reply to Micael Dias from comment #172)
> The patch from http://article.gmane.org/gmane.linux.acpi.devel/62717 on top
> of rc4 doesn't work for me.
> 
> Pressing the backlight keys I get the behaviour described in comment #97

How can that be? Sam says it works like a charm for him.

Do you have the latest BIOS, what does this return?

% dmesg | grep DMI
Comment 180 Micael Dias 2013-08-06 00:51:32 UTC
(In reply to Felipe Contreras from comment #179)
> How can that be? Sam says it works like a charm for him.

I don't know.

> Do you have the latest BIOS, what does this return?

Yes.

> dmesg | grep DMI
[    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.217 05/22/2013
Comment 181 Micael Dias 2013-08-06 01:30:08 UTC
(In reply to Felipe Contreras from comment #176)
> > I believe I tested the patch in bug #60682 WITH xorg option. To be honest I
> > think it's irrelevant because all that does (afaict) is force
> > acpi_osi="!Windows 2012" which we already know it's supposed to "work"
> > (backlight is controlled but doesn't send notifications).
> 
> Just test it.

Tested. Works as expected; backlight is handled by BIOS, no notifications are sent and many Fn keys don't work.
Comment 182 Felipe Contreras 2013-08-06 03:24:27 UTC
(In reply to Micael Dias from comment #180)

> > dmesg | grep DMI
> [    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.217
> 05/22/2013

Seems the only difference is the BIOS version:

[    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.215 11/02/2012
Comment 183 Micael Dias 2013-08-06 03:43:08 UTC
Maybe in his case the order of events is different than my case (similar to a race condition?). I always apply attachment "Add debug statement in intel backlight setting function" to my kernel compiles in order to view what's going on with dmesg.

Would be interesting to compare how his laptop behaves changing the brightness compared to mine. It's hard to see the problem I report on comment #128 and he might think that it's okay when it actually isn't.
It's also weird that "video.brightness_switch_enabled=0" doesn't make any difference for him.
Comment 184 Sam 2013-08-06 12:37:26 UTC
Hi,

[    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.217 05/22/2013
[    0.000000] DMI: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.215 11/02/2012

there is no public full changelog from 215 to 217.
BIOS 217:Update EC firmware
BIOS 216:Update new nVIDIA VBIOS
BIOS 215:Update new nVIDIA VBIOS (they say it was released on 2012.12.12 but mine was issued before... quite weird)

At the time I bought my laptop, windows 7 was included with it, and windows 8 was not yet available.

So maybe they add support for windows 8 in latest bios, and I heard windows 8 comes with a lot of changes in acpi...

There are interesting tests made here : https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1088146
Comment 185 Sam 2013-08-06 12:44:56 UTC
(In reply to Micael Dias from comment #183)
> Maybe in his case the order of events is different than my case (similar to
> a race condition?). I always apply attachment "Add debug statement in intel
> backlight setting function" to my kernel compiles in order to view what's
> going on with dmesg.
> 
> Would be interesting to compare how his laptop behaves changing the
> brightness compared to mine. It's hard to see the problem I report on
> comment #128 and he might think that it's okay when it actually isn't.
> It's also weird that "video.brightness_switch_enabled=0" doesn't make any
> difference for him.

- I'll try "Add debug statement in intel backlight setting function" as soon as possible to provide additional debug info.

- Did the screen flashed (event just a little bit) when doing your test on comment #128 ? Then it would be what I noticed in comment #168 item #3: "in 3.11-rc3 (and 3.11-rc4), video.brightness_switch_enabled=0 [...] It gave me back my backlight back, and then the Fn brightness keys were working but in a strange behavior (screen was a bit flashing when changing backlight and it hurt my eyes :-))" : it hurt my eyes a little bit because it created short flashes...
--> This wasn't the case when testing http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4...
Comment 186 Sam 2013-08-06 12:51:03 UTC
Other (similar) bug, other tests:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173107
Comment 187 Sam 2013-08-06 18:39:33 UTC
(In reply to Felipe Contreras from comment #178)
> > > Are you certain that this command:
> > > 
> > > echo 20 > /sys/class/backlight/acpi_video0/brightness
> > > 
> > > Works the same with or without acpi_osi="!Windows 2012"?
> > 
> > done as root on 3.11rc4 +
> > http://article.gmane.org/gmane.linux.acpi.devel/62717 :
> > 
> > echo 20 > /sys/class/backlight/acpi_video0/brightness 
> > -su: echo: write error: Invalid argument
> > 
> > cat /sys/class/backlight/acpi_video0/brightness
> > 10
> > (it remains at 10 whatever my brightness is)
> 
> Is that with "!Windows 2012"?
No (i mean it was with nothig specific at boot)

>Do you have an acpi_video1?
Yes, and it is working:
cat /sys/class/backlight/acpi_video1/brightness 
100 (full brightness)

echo 50 > /sys/class/backlight/acpi_video1/brightness
--> Gives me half brightness

All those tests were done on rc4+http://article.gmane.org/gmane.linux.acpi.devel/62717
Comment 188 Felipe Contreras 2013-08-06 18:41:49 UTC
(In reply to Sam from comment #187)
> (In reply to Felipe Contreras from comment #178)
> > > > Are you certain that this command:
> > > > 
> > > > echo 20 > /sys/class/backlight/acpi_video0/brightness
> > > > 
> > > > Works the same with or without acpi_osi="!Windows 2012"?
> > > 
> > > done as root on 3.11rc4 +
> > > http://article.gmane.org/gmane.linux.acpi.devel/62717 :
> > > 
> > > echo 20 > /sys/class/backlight/acpi_video0/brightness 
> > > -su: echo: write error: Invalid argument
> > > 
> > > cat /sys/class/backlight/acpi_video0/brightness
> > > 10
> > > (it remains at 10 whatever my brightness is)
> > 
> > Is that with "!Windows 2012"?
> No (i mean it was with nothig specific at boot)

I specifically asked if you noticed a difference doing that command with and without "!Windows 2012".
Comment 189 Sam 2013-08-06 19:18:14 UTC
Sorry I misunderstood you.

Yes, there is a difference with 3.11rc4 + http://article.gmane.org/gmane.linux.acpi.devel/62717 + acpi_osi="!Windows 2012":
- changing backlight now works on lightdm, before login (without !Windows 2012 it doesn't)
- it works perfectly after login
- both /sys/class/backlight/acpi_video0/brightness and /sys/class/backlight/acpi_video1/brightness are writable, with values between 0 and 10 only.
- /sys/class/backlight/acpi_video0/brightness doesn't update when I change brightness with fn keys, acpi_video1 does.

On the user point of view, this is even a better combination than without !Windows 2012.
Comment 190 Sam 2013-08-06 19:20:08 UTC
(In reply to Sam from comment #185)
> (In reply to Micael Dias from comment #183)
> > Maybe in his case the order of events is different than my case (similar to
> > a race condition?). I always apply attachment "Add debug statement in intel
> > backlight setting function" to my kernel compiles in order to view what's
> > going on with dmesg.
> > 
> > Would be interesting to compare how his laptop behaves changing the
> > brightness compared to mine. It's hard to see the problem I report on
> > comment #128 and he might think that it's okay when it actually isn't.
> > It's also weird that "video.brightness_switch_enabled=0" doesn't make any
> > difference for him.
> 
> - I'll try "Add debug statement in intel backlight setting function" as soon
> as possible to provide additional debug info.
> 
> - Did the screen flashed (event just a little bit) when doing your test on
> comment #128 ? Then it would be what I noticed in comment #168 item #3: "in
> 3.11-rc3 (and 3.11-rc4), video.brightness_switch_enabled=0 [...] It gave me
> back my backlight back, and then the Fn brightness keys were working but in
> a strange behavior (screen was a bit flashing when changing backlight and it
> hurt my eyes :-))" : it hurt my eyes a little bit because it created short
> flashes...
> --> This wasn't the case when testing
> http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4...

This is just one press on Fn+brightness up:
[  862.101302] i915 0000:00:02.0: intel_panel_set_backlight: level=96, max=255, freq=4882
[  862.101311] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 1837
[  862.101315] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=1837
[  862.106844] i915 0000:00:02.0: intel_panel_set_backlight: level=96, max=255, freq=4882
[  862.106853] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 1837
[  862.106859] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=1837
[  862.116353] i915 0000:00:02.0: intel_panel_set_backlight: level=96, max=255, freq=4882
[  862.116363] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 1837
[  862.116368] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=1837
[  862.117098] i915 0000:00:02.0: intel_panel_set_backlight: level=109, max=255, freq=4882
[  862.117101] i915 0000:00:02.0: intel_panel_set_backlight: after scale, level becomes 2086
[  862.117104] i915 0000:00:02.0: intel_panel_actually_set_backlight: set backlight level=2086

I really don't know what to think about this...
Comment 191 Felipe Contreras 2013-08-06 20:34:39 UTC
(In reply to Sam from comment #189)
> Sorry I misunderstood you.
> 
> Yes, there is a difference with 3.11rc4 +
> http://article.gmane.org/gmane.linux.acpi.devel/62717 + acpi_osi="!Windows
> 2012":
> - changing backlight now works on lightdm, before login (without !Windows
> 2012 it doesn't)
> - it works perfectly after login
> - both /sys/class/backlight/acpi_video0/brightness and
> /sys/class/backlight/acpi_video1/brightness are writable, with values
> between 0 and 10 only.
> - /sys/class/backlight/acpi_video0/brightness doesn't update when I change
> brightness with fn keys, acpi_video1 does.
> 
> On the user point of view, this is even a better combination than without
> !Windows 2012.

The patch http://article.gmane.org/gmane.linux.acpi.devel/62717 shouldn't make any difference.
Comment 192 Micael Dias 2013-08-07 01:44:58 UTC
(In reply to Sam from comment #185)
> - Did the screen flashed (event just a little bit) when doing your test on
> comment #128 ? Then it would be what I noticed in comment #168 item #3: "in
> 3.11-rc3 (and 3.11-rc4), video.brightness_switch_enabled=0 [...] It gave me
> back my backlight back, and then the Fn brightness keys were working but in
> a strange behavior (screen was a bit flashing when changing backlight and it
> hurt my eyes :-))" : it hurt my eyes a little bit because it created short
> flashes...

Yes, however it's barely noticable here. Could easily be unseen by the user.

> --> This wasn't the case when testing
> http://article.gmane.org/gmane.linux.acpi.devel/62717 on top of 3.11-rc4...

Ok, I decided to retest everything in case I got confused with the results. Let's call http://article.gmane.org/gmane.linux.acpi.devel/62717 "backlight-test-fix".

rc4 + backlight-test-fix:
- acpi_video0 works manually? NO
- acpi_video0 works with Fn keys? NO
- acpi_video1 works manually? YES
- acpi_video1 works with Fn keys? NO, gets out of sync (shows previous brightness value instead of current) with actual screen brightness when using Fn keys.
- intel_backlight works? YES, in all cases
- Fn keys do something before login in KDM: yes, however wrong
- more info: Fn keys behave as in comment #97

rc4 + backlight-test-fix + acpi_osi="!Windows 2012":
- acpi_video0 works manually? YES, max_brightness=10
- acpi_video0 works with Fn keys? NO, values stays unchanged
- acpi_video1 works manually? YES, max_brightness=10
- acpi_video1 works with Fn keys? NO, values stays unchanged
- intel_backlight works? YES, in all cases
- Fn keys do something before login in KDM: yes, works correctly
- more info: KDE gets no notifications of brightness changes and most other Fn keys don't work

rc4 + backlight-test-fix + video.brightness_switch_enabled=0:
- acpi_video0 works manually? NO
- acpi_video0 works with Fn keys? NO
- acpi_video1 works manually? YES, max_brightness=100
- acpi_video1 works with Fn keys? YES
- intel_backlight works? YES, in all cases
- Fn keys do something before login in KDM: NO
- more info: booted to black screen and I see flickering when using brightness Fn keys.

rc4 + backlight-test-fix + acpi_osi="!Windows 2012" + video.brightness_switch_enabled=0:
- acpi_video0 works manually? YES, max_brightness=10
- acpi_video0 works with Fn keys? NO, values stays unchanged
- acpi_video1 works manually? YES, max_brightness=10
- acpi_video1 works with Fn keys? NO, values stays unchanged
- intel_backlight works? YES, in all cases
- Fn keys do something before login in KDM: YES
- more info: KDE gets no notifications of brightness changes and most other Fn keys don't work


All this tests were made without the xorg.conf option.
Comment 193 Micael Dias 2013-08-07 01:49:42 UTC
Following the last test from my previous I rebooted to "rc4 + backlight-test-fix" and also booted with black screen, however changeable as I can use the brightness Fn keys before logging in.
Comment 194 Micael Dias 2013-08-07 01:59:08 UTC
rc4 + backlight-test-fix + video.brightness_switch_enabled=0 + xorg.conf option:
- acpi_video0 works manually? NO
- acpi_video0 works with Fn keys? NO
- acpi_video1 works manually? YES, max_brightness=100
- acpi_video1 works with Fn keys? NO, values stays unchanged
- intel_backlight works? YES, in all cases
- Fn keys do something before login in KDM: NO
- more info: works fine. dmesg differs from Sam's in quantity of events (tracked to be KDE's fault in comment #123) and max value; mine's "4882" and Sam's is "255"
Comment 195 Felipe Contreras 2013-08-08 00:53:00 UTC
(In reply to Micael Dias from comment #194)
> rc4 + backlight-test-fix + video.brightness_switch_enabled=0 + xorg.conf
> option:
> - acpi_video0 works manually? NO
> - acpi_video0 works with Fn keys? NO
> - acpi_video1 works manually? YES, max_brightness=100
> - acpi_video1 works with Fn keys? NO, values stays unchanged

None of these matter if you are using the xorg.conf option.
Comment 196 Micael Dias 2013-08-08 03:50:05 UTC
What do you mean it doesn't matter?

As far as I can tell a proper patch would remove the acpi interfaces in laptops that don't need it, and Windows 8 laptops shouldn't need it. Using the xorg.conf option confirms that if the acpi interfaces are gone, things will work correctly, no?

I believe the best short term "fix" would be to blacklist the ACPI interfaces for selected laptops.
Or even better, whitelist ACPI interfaces that don't follow the specs (report Win8 OSI but still handle backlight via ACPI).
Comment 197 Felipe Contreras 2013-08-09 19:32:28 UTC
(In reply to Micael Dias from comment #196)
> What do you mean it doesn't matter?
> 
> As far as I can tell a proper patch would remove the acpi interfaces in
> laptops that don't need it, and Windows 8 laptops shouldn't need it. Using
> the xorg.conf option confirms that if the acpi interfaces are gone, things
> will work correctly, no?

That's why I said testing acpi_videoX is irrelevant.
Comment 198 Christian Roeser 2013-08-13 06:51:08 UTC
Yust install 3.11.0-rc5 under a fresh Linux Mint installation and it works like a charm.
Comment 199 Aaron Lu 2013-08-14 06:08:20 UTC
Micael, Dan and Sam,

Does v3.11-rc5 without any additional tweaks(no cmdline option, no xorg.conf) work for you?
Comment 200 Micael Dias 2013-08-14 10:54:55 UTC
Works for me with the exception that userland appears to not be notified. (I get no popup stating the brightness level). It also works before logging in.

I also tested with video.brightness_switch_enabled=0 and it appears to work well, with notifications and all. However, brightness=0 gets me a turned off screen, which is fine for me. Doesn't work before logging in.
Comment 201 Micael Dias 2013-08-14 10:56:13 UTC
Forgot to mention that without any option I am also able to get the brightness low enough to turn off the screen.
Comment 202 Sam 2013-08-14 21:22:59 UTC
3.11-rc5
- witout tweaks : brightness special keys works, but only after I log in. I have to mention that wireless special key doesn't work
- with video.brightness_switch_enabled=0: exactly same results
- with acpi_osi=!Windows 2012 : Both brightness and wireless keys work. I can change brightness before and after loggin in, and user space is well notified. This is the perfect combination.

(I know I mentioned before that acpi_osi=!Windows 2012 didn't gave me results, but this was on previous version, so I guess something has changed here).

Micael, could you tell us about the wireless special key, just to see if the behavior is different?
Comment 203 Aaron Lu 2013-08-16 00:56:12 UTC
(In reply to Micael Dias from comment #200)
> Works for me with the exception that userland appears to not be notified. (I
> get no popup stating the brightness level). It also works before logging in.
> 
> I also tested with video.brightness_switch_enabled=0 and it appears to work
> well, with notifications and all. However, brightness=0 gets me a turned off
> screen, which is fine for me. Doesn't work before logging in.

The brightness_switch_enabled shouldn't affect event delivery, perhaps KDE is doing something fancy? Possible to test another GUI, say GNOME? Thanks.
Comment 204 Micael Dias 2013-08-16 17:24:05 UTC
(In reply to Sam from comment #202)
> Micael, could you tell us about the wireless special key, just to see if the
> behavior is different?

Confirmed, not working here either.

(In reply to Aaron Lu from comment #203)
> The brightness_switch_enabled shouldn't affect event delivery, perhaps KDE
> is doing something fancy? Possible to test another GUI, say GNOME? Thanks.

Indeed it works fine with GNOME.
Comment 205 Aaron Lu 2013-08-21 06:24:33 UTC
(In reply to Sam from comment #202)
> 3.11-rc5
> - witout tweaks : brightness special keys works, but only after I log in. I
> have to mention that wireless special key doesn't work

This is not expected. The hotkey for backlight should always work no matter if you are using a GUI and logged in or not or you are on console. Please attach your acpidump. BTW, please confirm your /sys/class/backlight/acpi_video work and acpi_listen can receive backlight events.

> - with video.brightness_switch_enabled=0: exactly same results

This is expected.
Comment 206 Sam 2013-08-21 18:20:08 UTC
(In reply to Aaron Lu from comment #205)
> (In reply to Sam from comment #202)
> > 3.11-rc5
> > - witout tweaks : brightness special keys works, but only after I log in. I
> > have to mention that wireless special key doesn't work
> 
> This is not expected. The hotkey for backlight should always work no matter
> if you are using a GUI and logged in or not or you are on console. Please
> attach your acpidump. BTW, please confirm your
> /sys/class/backlight/acpi_video work and acpi_listen can receive backlight
> events.
> 
> > - with video.brightness_switch_enabled=0: exactly same results
> 
> This is expected.

Hi,
I just tried with 3.11-tc6 and I confirm this is happening: same results as rc5, with or without video.brightness_switch_enabled=0
rc6 without tweaks:
- acpi_video0 works manually? NO (Read incorrect, cannot write)
- acpi_video0 works with Fn keys? NO (Read incorrect, cannot write)
- acpi_video1 works manually? YES (R/W)
- acpi_video1 works with Fn keys? YES (R/W)

Can you give me a clue on how to check if acpi_listen can receive backlight events?

I will upload my acpidump right now
Comment 207 Sam 2013-08-21 18:21:16 UTC
Created attachment 107272 [details]
acpidump N56VZ BIOS215
Comment 208 Sam 2013-08-21 18:22:29 UTC
(In reply to Micael Dias from comment #204)
> (In reply to Sam from comment #202)
> > Micael, could you tell us about the wireless special key, just to see if
> the
> > behavior is different?
> 
> Confirmed, not working here either.

Is it working with acpi_osi=!Windows 2012 ?
Comment 209 Aaron Lu 2013-08-22 00:38:22 UTC
(In reply to Sam from comment #206)
> Can you give me a clue on how to check if acpi_listen can receive backlight
> events?

Run acpi_listen and then press backlight hotkey, see if any events get captured.
Comment 210 Micael Dias 2013-08-22 14:32:51 UTC
(In reply to Sam from comment #208)
> Is it working with acpi_osi=!Windows 2012 ?

Yes, however I get no notifications when I press the button.
Comment 211 Aaron Lu 2013-08-23 07:49:16 UTC
Hi Sam,

Please confirm the value of /sys/module/video/parameters/brightness_switch_enabled is Y when you boot without video.brightness_switch_enabled=0 cmdline option.
Comment 212 Sam 2013-08-23 17:01:47 UTC
(In reply to Aaron Lu from comment #211)
> Hi Sam,
> 
> Please confirm the value of
> /sys/module/video/parameters/brightness_switch_enabled is Y when you boot
> without video.brightness_switch_enabled=0 cmdline option.

I confirm the value is:
Y without video.brightness_switch_enabled=0
N with video.brightness_switch_enabled=0
Comment 213 Sam 2013-08-23 17:07:41 UTC
(In reply to Sam from comment #206)
> (In reply to Aaron Lu from comment #205)
> > (In reply to Sam from comment #202)
> > > 3.11-rc5
> > > - witout tweaks : brightness special keys works, but only after I log in.
> I
> > > have to mention that wireless special key doesn't work
> > 
> > This is not expected. The hotkey for backlight should always work no matter
> > if you are using a GUI and logged in or not or you are on console. Please
> > attach your acpidump. BTW, please confirm your
> > /sys/class/backlight/acpi_video work and acpi_listen can receive backlight
> > events.
> > 
> > > - with video.brightness_switch_enabled=0: exactly same results
> > 
> > This is expected.
> 
> Hi,
> I just tried with 3.11-tc6 and I confirm this is happening: same results as
> rc5, with or without video.brightness_switch_enabled=0
> rc6 without tweaks:
> - acpi_video0 works manually? NO (Read incorrect, cannot write)
> - acpi_video0 works with Fn keys? NO (Read incorrect, cannot write)
> - acpi_video1 works manually? YES (R/W)
> - acpi_video1 works with Fn keys? YES (R/W)
> 
> Can you give me a clue on how to check if acpi_listen can receive backlight
> events?
> 
> I will upload my acpidump right now

In rc6 with or without video.brightness_switch_enabled=0, acpi_listen always receive events
Comment 214 Aaron Lu 2013-08-26 02:33:28 UTC
Sam,

Note that there are 100 levels and each hotkey press will adjust only one level by video module, so please try to press the hotkey a lot of times(say 90) and then see if it makes any difference.
Comment 215 Aaron Lu 2013-09-03 00:53:18 UTC
commit b3b301c5fed8a0868e56c98b922cb0c881b3857d
Author: Felipe Contreras <felipe.contreras@gmail.com>
Date:   Sat Aug 3 23:00:25 2013 +0200

    ACPI / video: improve quirk check in acpi_video_bqc_quirk()

has entered Linus' tree.
Comment 216 Sam 2013-09-03 19:30:54 UTC
(In reply to Aaron Lu from comment #214)
> Sam,
> 
> Note that there are 100 levels and each hotkey press will adjust only one
> level by video module, so please try to press the hotkey a lot of times(say
> 90) and then see if it makes any difference.

Hi, sorry for the long delay.
I am no sure to understand exactly what should I test.

I takes only 5 hotkey press to go from min brightness to max brightness and vice-versa.
/sys/class/backlight/acpi_video1/brightness goes from 0 to 10

If I continue to press a special key a lot of more times, I don't notice any change.

Should I expect more? Or do you want me to do a specific test?

Regards,
Sam
Comment 217 Aaron Lu 2013-09-04 00:35:35 UTC
(In reply to Sam from comment #216)
> (In reply to Aaron Lu from comment #214)
> > Sam,
> > 
> > Note that there are 100 levels and each hotkey press will adjust only one
> > level by video module, so please try to press the hotkey a lot of times(say
> > 90) and then see if it makes any difference.
> 
> Hi, sorry for the long delay.
> I am no sure to understand exactly what should I test.
> 
> I takes only 5 hotkey press to go from min brightness to max brightness and
> vice-versa.
> /sys/class/backlight/acpi_video1/brightness goes from 0 to 10

Are you using !Windows 2012?

For all the tests, please do not use any kernel cmdline option.
Comment 218 Sam 2013-09-04 19:33:35 UTC
(In reply to Aaron Lu from comment #217)
> (In reply to Sam from comment #216)
> > (In reply to Aaron Lu from comment #214)
> > > Sam,
> > > 
> > > Note that there are 100 levels and each hotkey press will adjust only one
> > > level by video module, so please try to press the hotkey a lot of
> times(say
> > > 90) and then see if it makes any difference.
> > 
> > Hi, sorry for the long delay.
> > I am no sure to understand exactly what should I test.
> > 
> > I takes only 5 hotkey press to go from min brightness to max brightness and
> > vice-versa.
> > /sys/class/backlight/acpi_video1/brightness goes from 0 to 10
> 
> Are you using !Windows 2012?
> 
> For all the tests, please do not use any kernel cmdline option.

Yes I was, sorry for my imprecision.

I retried the test with 3.11 and no specific commandline.

- /sys/class/backlight/acpi_video0/brightness remains at 10
- /sys/class/backlight/acpi_video0/brightness goes from 0 to 100 with 17 key press (and 0 is no-backlight, as if the screen was off)
- /sys/class/backlight/intel_backlight/brightness goes from 0 to 4845
Comment 219 Aaron Lu 2013-09-05 01:26:25 UTC
(In reply to Sam from comment #218)
> 
> Yes I was, sorry for my imprecision.
> 
> I retried the test with 3.11 and no specific commandline.
> 
> - /sys/class/backlight/acpi_video0/brightness remains at 10
> - /sys/class/backlight/acpi_video0/brightness goes from 0 to 100 with 17 key
> press (and 0 is no-backlight, as if the screen was off)
> - /sys/class/backlight/intel_backlight/brightness goes from 0 to 4845

So do you still have the problem of not being able to adjust the brightness level with Fn key before log in?
Comment 220 Sam 2013-09-06 20:39:49 UTC
(In reply to Aaron Lu from comment #219)
> So do you still have the problem of not being able to adjust the brightness
> level with Fn key before log in?

Without any tweak, I cannot adjust brightness before log in.
With acpi_osi="!Windows 2012" I can adjust it before and after.
Comment 221 Aaron Lu 2013-09-07 14:39:57 UTC
Hi Sam,

OK, good to know this. Please do not use any kernel cmdline option, when it boots to login window, switch to a console by ctrl+alt+Fx, then run acpi_listen and press backlight hotkey, see if the event is generated.
Comment 222 Sam 2013-09-10 17:33:44 UTC
(In reply to Aaron Lu from comment #221)
> Hi Sam,
> 
> OK, good to know this. Please do not use any kernel cmdline option, when it
> boots to login window, switch to a console by ctrl+alt+Fx, then run
> acpi_listen and press backlight hotkey, see if the event is generated.

Hi,

yes, events are generated.
I guess this is half the way to make it work...?

Regards,
Sam
Comment 223 Aaron Lu 2013-09-11 00:38:09 UTC
(In reply to Sam from comment #222)
> (In reply to Aaron Lu from comment #221)
> > Hi Sam,
> > 
> > OK, good to know this. Please do not use any kernel cmdline option, when it
> > boots to login window, switch to a console by ctrl+alt+Fx, then run
> > acpi_listen and press backlight hotkey, see if the event is generated.
> 
> Hi,
> 
> yes, events are generated.

Good.

> I guess this is half the way to make it work...?

Did you try pressing the hotkey a lot of times?
Comment 224 Sam 2013-09-11 20:22:58 UTC
(In reply to Aaron Lu from comment #223)
> Did you try pressing the hotkey a lot of times?

Oooooooooooohhhhhhhhhhh yyyyyyyyyyyyyyeeeeeaaaaaaaaaahhhhhhhhhhhhh

OK, so I tried pressing the hotkey a lot of times and... it is working!
(but very slowly indeed)

I looked at /sys/class/backlight/acpi_video0/brightness and it goes step by step from 100 (full brightness) to 0 (no brightness at all)... One key press: one step, as you said in a previous post.

I didn't noticed it in my previous test as I was used to move from high brightness to low brightness in only a few key presses.

For my understanding, I guess GNOME is handling brightness keys in a more agressive way than the console? Or am I totally wrong?
Comment 225 Aaron Lu 2013-09-16 01:53:17 UTC
(In reply to Sam from comment #224)
> For my understanding, I guess GNOME is handling brightness keys in a more
> agressive way than the console? Or am I totally wrong?

That's right, except that the console should be replace with the kernel's ACPI video module.