Bug 52951
|
Description
Micael Dias
2013-01-23 17:53:04 UTC
acpi_listen only reports events if kernel booted with "acpi_osi=". Created attachment 91741 [details]
Original DSDT table (BIOS v 216)
Brightness keys are methods _Q0E and _Q0F.
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. 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. 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. 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) 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? 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. 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. 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. (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. this bug affects me on ubuntu 13.04 beta with 3.8.0-15-generic kernel on asus N56VZ. lspci output please. And next time, please attach the output of acpidump, thanks. Created attachment 97611 [details]
acpidump
acpidump log for asus N56VZ/VJ
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) Hi Ashish, Thanks for the information! BTW, I saw this system has two vga controllers, which one are you using then? 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. 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? 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. 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. 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. 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. @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. @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? 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. @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. (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. 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.
Or you could even try spoofing as "Windows 2012" since the default behavior is for Linux to spoof as Windows NT. 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 (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. 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. 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!) @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. 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. 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 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"? (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. 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) (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? 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. Created attachment 98981 [details] dmesg from v3.8 with patch from comment #19 (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. 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. 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". (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. 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.
I have made a video showing the laptop's behaviour with your kernel branch: http://www.youtube.com/watch?v=s6HxuXwFxzc 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. 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. 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. :) 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. 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. (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. 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. 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.
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. 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. Created attachment 100081 [details]
dmesg from aarons kernel with acpi fixes
This is without the new flags.
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.
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. 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"... (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. 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. 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.
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 :-) 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 :) (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! (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 :) Forgot to mention. It still works fine with the newest changes. 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! 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. @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. 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. 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. It's still working fine here. 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. 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! (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. 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. Just tested the mainline tree with the 4 patches and indeed it works. @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 (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 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? 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 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 Just installed 3.11rc2, working great! :) 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. 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 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? 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... 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. Yes, an event is correctly shown for each keypress. 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? 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. 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? 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. 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. (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. 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.
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 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? 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. (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. /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 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. 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. I suppose all the above tests are done without the acpi_osi="!Windows2012" cmdline? Hi Aaron, I can confirm that it works perfectly on 3.11-rc2 without any specific cmdline (ie without acpi_osi="!Windows2012") I also tried with acpi_osi="!Windows2012" but I didn't notice any difference (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...? (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. 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. Applying 8e5c2b776ae4c35f54547c017e0a943429f5748a to rc2 makes it not work correctly again. Behaves like rc3. (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? 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. (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. 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. 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 :) (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. 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. Yes, I think so. I use GNOME, so the behavior is different with KDE. 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. 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')" I remember hotkey doesn't work with ACPI video interface on this system due to broken _BQC, things have changed? 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. To clarity, the brightness keys work fine again after logging in. 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. 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. (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. Created attachment 107085 [details]
Test quirk
Apply this on top of v3.11-rc3, then attach the dmesg output:
% dmesg | grep 'acpi: video: quirk'
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'
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. @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. (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. 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. (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. (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. (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. 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. (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. (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. (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 (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. (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. (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. (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. (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? (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. (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. (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); (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. (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. (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. (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. (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. (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??? (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. 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. > (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. (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. (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). (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. (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. (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. 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 (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? 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 (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. (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. (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... 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 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. 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. And finally, patched kernel + video.brightness_switch_enabled=0 + xorg.conf option works fine. Same as comment #119. (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. (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. (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%? (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 (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 (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. (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 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. 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 (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... Other (similar) bug, other tests: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173107 (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 (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". 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. (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... (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. (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. 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. 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" (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. 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). (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. Yust install 3.11.0-rc5 under a fresh Linux Mint installation and it works like a charm. Micael, Dan and Sam, Does v3.11-rc5 without any additional tweaks(no cmdline option, no xorg.conf) work for you? 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. Forgot to mention that without any option I am also able to get the brightness low enough to turn off the screen. 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? (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. (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. (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. (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 Created attachment 107272 [details]
acpidump N56VZ BIOS215
(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 ? (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. (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. 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. (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 (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 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. 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. (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 (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. (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 (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? (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. 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. (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 (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? (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? (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. |