The brightness control keys (Fn+F4 and Fn+F5) does not work on the Dell XPS17 L502X (brightness does not change). Other function keys are working properly. Strange thing is that the value stored in /sys/class/backlight/acpi_video0/brightness changes as the function keys are pressed (from 0 to 15), there is just no visible changes. I tried a few things: - booting with acpi_backlight=vendor does not solve the problem (the brightness path changes to /sys/class/backlight/dell_backlight/brightness, and the function keys does not seem to have any effect - the graphics card is an nvidia 555M, I tried with nvidia module, nouveau and in console mode, no changes - bug has also been reported to ubuntu, at https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/762670 I'm using Debian sid/unstable, with kernel 3.0.1 (vanilla, no additional patch). Will attach dsdt, lspci and dmesg to the bugreport.
Created attachment 71442 [details] dmesg
Created attachment 71452 [details] lspci
Created attachment 71462 [details] DSDT The DSDT, dumped by acpidump Note that there is an error in the _DSM function, line 8387
Please post the actual acpidump, I would like to look at the error in the disassembly of _DSM.
Created attachment 71472 [details] acpidump Result of the command 'acpidump -o dump.acpi'
Error is caused because NVOP cannot be resolved, and it is actually a control method. Disassembler has no way of knowing this, so it gets confused: External (NVOP, IntObj) P8XH (Zero, 0xF5) Return (NVOP) Arg0 Arg1 Arg2 Arg3 This is probably what the actual code should look like: P8XH (Zero, 0xF5) Return (NVOP (Arg0, Arg1, Arg2, Arg3)) NVOP may appear in a dynamically loaded SSDT, it is not defined in any of the SSDTs that appear in the ACPI dump. This is fundamental issue with AML code where the disassembler cannot properly reproduce the original code. There is no "argument" information associated with a compiled method, so the actual method declaration must be present for proper disassembler. The -e option to iASL should help, if you can dump the dynamically loaded SSDTs (shown below, from dmesg.) [ 1.004816] ACPI: SSDT 00000000bf710718 0067C (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 1.005393] ACPI: Dynamic OEM Table Load: [ 1.005396] ACPI: SSDT (null) 0067C (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 1.016327] ACPI: SSDT 00000000bf711a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 1.017005] ACPI: Dynamic OEM Table Load: [ 1.017007] ACPI: SSDT (null) 00303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 1.027872] ACPI: SSDT 00000000bf70fd98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) [ 1.028426] ACPI: Dynamic OEM Table Load: [ 1.028428] ACPI: SSDT (null) 00119 (v01 PmRef ApCst 00003000 INTL 20061109)
Thanks for your help. I must admit I don't see what to do now (I'm a bit lost, and not familiar with ACPI so I may be missing something obvious). I tried to run iasl -d -e on the DSDT.dat file, but this results more or less in the same file DSDT.dsl (the error is still present). I also tried some commands like iasl -eSSDT1,SSDT2,SSDT3,SSDT4,SSDT5,SSDT6 -d DSDT with no more luck About the dynamically loaded SSDTs, I don't know how to dump them. I have looked in the /sys/firmware/acpi/tables/dynamic/ directory, there are 3 files (SSDT4 to SSDT6). I don't know if they are needed, so I'm creating a tarball with all files (dynamic or static) and attaching it. That said, I ran a iasl -d on each DSDT file and could not find a reference to NVOP. Also, I'm wondering about the relation between this and the problem - could the problem with brightness be caused by an error in _DSM, or is this just a wrong supposition I was doing ?
Created attachment 71492 [details] DSDT + all SSDTs DSDT and SSDT tables from /sys/firmware/acpi/tables/ + SSDT tables from /sys/firmware/acpi/tables/dynamic/
I can only speak to the disassembler error. Unless you are receiving a message like "NVOP", then there is probably no runtime issue with the _DSM.
What's the latest kernel tested?
ping...