Running Ubuntu kernel 3.8.0-17.27 (apparently based off 3.8.5). wKeys Working better than ever before, definitely - the fn-f5 and fn-f6 buttons now changing with gnome/unity indications 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. (Aaron: "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 :( ) 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.
Hi Dan, Thanks for the report. Please attach dmesg, lspci and acpidump output here, thanks.
Hi Dan, Any update? Thanks.
Created attachment 99611 [details] dmesg output
Created attachment 99621 [details] lspci output
Created attachment 99631 [details] acpidump output
Aaron, sorry I thought I had already done it. Now done.
Thanks Dan. Can you please test the following kernel tree? https://github.com/aaronlu/linux.git, branch acpi_video. I think the patches there should fix your problem. And when test that kernel, please boot with acpi.debug_layer=0x10000000 acpi.debug_level=0x4 to kernel command line, and attach dmesg.
Sorry, took me a while to get round to building. Hotkeys now work perfectly. Thanks! dmesg output with requested boot args attached.
Created attachment 100201 [details] dmesg output acpi.debug_layer=0x10000000 acpi.debug_level=0x4
@Aaron: Quick question: How will I know when your branch changes get merged into Linus'?
Thanks for your test. I'll cc you when submitting the patch.
Patches in Rafael's acpi-video branch. 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) 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
Does booting with acpi_osi="!Windows 2012" work? This needs to be reopened, as these patches were reverted.
This bug needs to be reopened. I installed a 3.11.8 kernel and it made my system worse. I'm running , formerly pristine, Linux Mint 15 with the default 3.8.0-33, apparently a Ubuntu based kernel based on a 3.8.8 kernel. Function keys: F1 and F9-12 all worked, F7 and F8 untested, F2 thru F4 did not work, and F5 and F6 "worked" by setting the screen backlight to 90 for down and 91 for up. I could push values into the keyboard backlight and make it work and push values in either acpi_video1 or the intel video and change the brightness. Once, just once, I also got a message pop up letting me know the backlight changed. When installing the, Ubuntu kernel-ppa/mainline/v3.11.8-saucy the dkms module piece failed to build. The kernel boots and the system appears to be functional. However, now F1, which puts the pc into hibernate, now does hibernte but bricks the machine thereafter. This is the error I got using dpkg to install the 3.11.8 kernel. I realize this isn't pure downline kernel, but, I'm not running pure kernel, and likely a pure kernel would have other issues. I did note this is in the dkms part of the system. Let me know what you need. I removed the 3.11 kernel for now, but still have it. Perhaps I need some files/packages to successfully build all the modules. CC [M] /var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf/dirops.o /var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf/dirops.c:292:5: error: unknown field ‘readdir’ specified in initializer /var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf/dirops.c:292:5: warning: initialization from incompatible pointer type [enabled by default] /var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf/dirops.c:292:5: warning: (near initialization for ‘sf_dir_fops.flush’) [enabled by default] make[2]: *** [/var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf/dirops.o] Error 1 make[1]: *** [/var/lib/dkms/virtualbox-guest/4.2.10/build/vboxsf] Error 2 make: *** [_module_/var/lib/dkms/virtualbox-guest/4.2.10/build] Error 2 make: Leaving directory `/usr/src/linux-headers-3.11.8-031108-generic'
What do you mean by 'bricks the machine thereafter', is the machine not usable anymore that you need to return it to your vendor's support place for a new one? BTW, the dkms error has nothing to do with ACPI.
By bricking, I mean that the computer becomes completely non-responsive locally and remotely. Requiring a hard reset. It's not a permanent bricking of the PC, but neither is it a crash that I can detect. Perhaps some debug logging to a remote disk might capture the point of failure.
I don't see how this relates to ACPI backlight control. If you have problem with hibernation, feel free to submit a new bug about that.
Well I don't want to sidetrack the issue of the backlight control. I did also state that the backlight keys don't work anymore even to the minor state they did before. I included all the other info as seems to be all connected to me, relating to the function keys. With stock kernel 3.8.8 (Ubuntufied) The backlight keys set the brightness to 90 and 91 (usually without notification). With the Ubuntu downline 3.11.8 kernel nothing, screen doesn't even flicker like it did before. With the 3.8.8 every time the keys are pressed, the screen flickers to some extent. I'm assuming it is a result of a very rapid, but noticeable down and up setting of the backlight. I haven't tried grabbing any messages. I've never done any low-level diagnosis in Linux. But will be happy to do so if you point me to a howto or tell me what you need for this case. My Mint out of the box installed (last Monday on a new Asus) semi-works with the keys. I've written scripts to fully control the functions for the F3 to F6 keys in 3.8. I could modify these scripts and install them system-wide and tie them to the backlight keys via a keymap. But it would likely break if I switch from the Intel to the NVidia video. They're dumb scripts. All I did with this system is wipe the Windows partitions, turn off the secure boot, and enable the old style BIOS function.
Your laptop is also ASUS N56VJ, right? Please attach your acpidump: # acpidump > acpidump.txt And different laptops are different, so let's focus on a single model. If you have multiple models that have problem, file different bugs for them. There was a bug in the firmware and we had a workaround fix for it by commit: 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() It entered mainline as of v3.11, so please test kernels with v3.11 or above. Please show me your /sys/class/backlight: $ ls /sys/class/backlight And there should be two directories acpi_video0 and intel_backlight, enter them, echo some values to the brightness file, see if backlight level gets changed. For a description of the backlight sysfs interface, take a look at: https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight
Created attachment 115121 [details] acpi dump Here is the acpidump under a 3.11 kernel It is an N56VJ laptop. ~ > ls /sys/class/backlight acpi_video0 acpi_video1 intel_backlight pushing values into either acpi_video1 or intel_backlight change the screen backlight normally. running acpi_listen and pressing the function keys shows they are being trapped as: # acpi_listen video LCDD 00000087 00000000 video LCDD 00000086 00000000 dmesg shows these errors on boot: [ 1.061442] ACPI Error: Needed [Buffer/String/Package], found [Integer] ffff88019f6b8900 (20130517/exresop-590) [ 1.061446] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0._DSM] (Node ffff8801a5c723c0), AE_AML_OPERAND_TYPE (20130517/psparse-536) [ 1.061449] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG0.PEGP._DSM] (Node ffff8801a5c8ac08), AE_AML_OPERAND_TYPE (20130517/psparse-536)
Also dmesg and dmi: # dmesg > dmesg # dmidecode > dmi
Created attachment 115131 [details] dmesg Here's the dmesg output
Created attachment 115141 [details] dmidecode Here's the dmidecode result
Possible to disable the discrete graphics card?
Well, I've been told anything is possible. But if I disable the discrete graphics card, it'll make Blender renders really painful. Not that I do that that often, but I am working on a making a Blender graphics movie. I haven't really looked into disabling one in any of my systems. I'm investigating the best procedure to do that. Still shutting off discrete graphics is a hack, and shouldn't be relied on as a permanent solution. Once I shut it off, I suppose you'll want me to test again. Any diagnostics you'd want again?
Once you shut it off, I suppose the problem with backlight would be gone. I've no idea how the two graphics cards are working together. When you are using the two graphics card together, which X driver is in use?
X is using the Intel driver. It loads the nouveau and attempts to load the nvidia driver, which isn't installed. Disabling, the discrete graphics card does indeed make the backlight keys work very nicely, in the 3.11 kernel. I got all kinds of errors from the discrete card driver when I disabled that. I used vgaswitcheroo, which was installed and enabled by default. The 3.8 system really didn't like me switching it off, and the system locked up when trying to reboot. I haven't tested the keys with the discrete on and the Intel off. Not even sure I can make that happen, without installing this bumblebee project I read about. Doesn't seem to have an apt entry. Anyway to make the keys work without disabling the discrete graphics, and will there a patch for the 3.8 kernel?
You can specify which backlight interface X driver should pick up by editing /etc/xorg.conf: Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
No stable patch for v3.8, as the change is deemed a behavior change: http://www.spinics.net/lists/linux-acpi/msg43976.html