Created attachment 73432 [details] dmesg with acpi.debug_level=39 acpi.debug_layer=0x10000000 Setting display brightness level, either via the hotkeys or via /sys/class/backlight/acpi_video1/brightness, has no effect. Booting with acpi_backlight=vendor does not make the hotkeys work (but removes the device from /sys/class/backlight). Changing the brightness via /sys/class/backlight/acpi_video1/brightness has only the result that the new value can after that be read from brightness or actual_brightness. Booting with acpi.debug_level=39 acpi.debug_layer=0x10000000 reports finding 11 backlight levels: [ 45.528981] video-0732 [00] video_init_brightness : found 11 brightness levels OTOH dmesg contains this message (this may be related to the fact that this laptop has dual Intel/Radeon GPUs): [ 45.529448] video: probe of LNXVIDEO:00 failed with error -5 See attachments: 1) dmesg with acpi.debug_level=39 acpi.debug_layer=0x10000000 2) lspci -vvv output 3) acpidump output
Created attachment 73433 [details] lspci -vvvnn output
Created attachment 73434 [details] acpidump output
I have the same problem using kernel 3.4 and 3.5. The patch for bug #43168 solves the issue. https://bugzilla.kernel.org/show_bug.cgi?id=43168#c15
On a similar HP Pavilion? That patch does not seem to solve the problem for me. Moreover the dmesg output is different, and in my case the kernel believes it is using backlight, it just does not have any effect.
Sorry, I meant I had the same symptoms, but with a Sony VAIO. - Brightness control found - Brightness can be changed in the proc files, but has no physical effect - the video probe failed with error -5 Maybe you should try the patch from bug #43168 comment #8 to see why video probing fails and post the dmesg output
The reason for video probe failing seems to be the same as in #43168: [ 29.593330] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [ 29.717221] acpi device:2f: registered as cooling_device8 [ 29.717723] Video Debug: Failed to evaluate _DOS [ 29.717734] Video Debug: acpi_video_bus_start_devices failed [ 29.717943] video: probe of LNXVIDEO:00 failed with error -5 [ 29.833196] acpi device:3c: registered as cooling_device8 [ 29.834153] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input10 [ 29.834240] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 29.834307] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
After applying the patch from bug #43168 there are in fact two backlight devices (which makes sense because the probe for the other one failed previously). When I use the brightness keys in X to change brightness, both /sys/class/backlight/acpi_video[01]/brightness change, as does the actual_brightness for both devices. They can also be changed by writing to those files. Unfortunately none of this has any effect whatsoever on the actual brightness of the backlight.
Same issue here, on an HP Pavilion dv7-6c95dx with Intel Core i7-2670QM (Sandy Bridge) running Gentoo Linux with kernel 3.4.9. These errors always come in pairs, whenever I try to use the keys Fn+F2 or Fn+F3 (brightness adjustment): ACPI Error: [^^^PEG0.PEGP.DD02] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__._Q17] (Node ffff880246833b18), AE_NOT_FOUND (20120320/psparse-536) The thing that really frustrates me is that this seems to come and go: when I initially bought this computer, it was not working; then after I found out about the acpi_backlight=vendor option, and it started working; subsequently an upgrade or kernel recompilation broke it, but after some other upgrade it resumed working; now it magically stopped working again. Right now I’m playing again with the kernel options and the packages I upgraded recently (including xfce4-power-manager) to see if I manage to figure out what is it that determines whether or not the brightness adjustment works.
Forgot to mention, intel_backlight from intel-gpu-tools now works, just like manually executing echo 1500 >/sys/class/backlight/intel_backlight/brightness I don’t know if they would’ve worked the previous times the backlight adjustment didn’t work.
(In reply to comment #8) > ACPI Error: [^^^PEG0.PEGP.DD02] Namespace lookup failure, AE_NOT_FOUND > (20120320/psargs-359) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__._Q17] (Node > ffff880246833b18), AE_NOT_FOUND (20120320/psparse-536) It is not clear what is going on. The object [^^^PEG0.PEGP.DD02] does in fact appear in one of the SSDTs, and the _Q17 method executes properly here: Executing with AcpiExec: > acpiexec dsdt.dat ssdt6.dat - find DD02 \_SB_.PCI0.PEG0.PEGP.DD02 Device 00504430 04 \_SB_.PCI0.GFX0.DD02 Device 004D17E0 01 - find _Q17 \_SB_.PCI0.LPCB.EC__._Q17 Method 004C0420 01 Args 0 Len 002E Aml 00492187 - eval \_SB_.PCI0.LPCB.EC__._Q17 Evaluating \_SB_.PCI0.LPCB.EC__._Q17 [AcpiExec] Global: Received a Device Notify on [DD02] 004D17E0 Value 0x87 (Device Specific) [AcpiExec] Global: Received a Device Notify on [DD02] 00504430 Value 0x87 (Device Specific) 0x2 Outstanding allocations after evaluation of \_SB_.PCI0.LPCB.EC__._Q17 No object was returned from evaluation of \_SB_.PCI0.LPCB.EC__._Q17 - This is with ACPICA version 20120913. We may have to attempt to reproduce the problem with version 20120320.
Today I decided to grab the bull by the horns, so I did a few more attempts. First, I’m now running a stock 3.6.1 kernel. This is what I get now: ACPI Error: [^^^PEG0.PEGP.DD02] Namespace lookup failure, AE_NOT_FOUND (20120711/psargs-359) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__._Q18] (Node ffff880246833b40), AE_NOT_FOUND (20120711/psparse-536) Basically, it looks like the only change is the version of ACPICA I’m running; everything else is still the same: the buttons don’t work, but I can manually adjust the brightness echoing the new level to sysfs. I did notice today that I’m getting notifications in my syslog from acpid; it seems to actually receive the keypresses, it just doesn’t know what to do with them. So I quickly wrote an acpid event handler which invokes a shell script to do the adjustment matching the key that was pressed, and now the keys magically work! I’m not sure I would call it a fix, since I still get the namespace lookup failure, but in the end I got the functionality I was after, so I’m good for now. Of course if you want me to test kernel patches or provide more information, I’m still available. Also, if anyone reading is interested in the acpid script, I can attach the two files here.
I think Sami and Raffaello have two different problem. ACPI Error: [^^^PEG0.PEGP.DD02] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__._Q17] (Node ffff880246833b18), AE_NOT_FOUND (20120320/psparse-536) this error message only exists in Raffaello's box, right? Raffaello, please attach the acpidump of your box. Bob, you are probably looking at Sami's acpidump which does not have the ACPICA error message. (In reply to comment #9) > Forgot to mention, intel_backlight from intel-gpu-tools now works, just like > manually executing > > echo 1500 >/sys/class/backlight/intel_backlight/brightness > Sami, does this work for you? or you still have two entries under /sys/class/backlight/, while none of them actually works?
Created attachment 86311 [details] acpidump of system with acpica error
I did not realize that the original reporter’s issue does NOT involve the acpica error message I get. If so, sorry about diverting the bug. I will create a new separate one.
(In reply to comment #13) > Created an attachment (id=86311) [details] > acpidump of system with acpica error External (\_SB_.PCI0.PEG0.PEGP.DD02) this is the problem, there is no \_SB_.PCI0.PEG0.PEGP.DD02 device defined in the ACPI namespace actually. :)
Zhang: I cannot test, as I no longer have the laptop. But with the then-current kernel I'm fairly sure I explored everything in /sys/class/backlight/ and got nothing to affect the brightness.
well, as you no longer have the laptop, I'd prefer to close the bug for now. I'll reopen it when there is someone own the same laptop that can be used for debugging.