Bug 13577
| Summary: | Broken backlight control on Acer Aspire 8930G due to buggy DSDT/ACPI Video | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Hector Martin (marcan) |
| Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | lenb, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.29 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Disassembled DSDT
patch: support backlight control without _DOS refreshed patch refreshed patch dmesg after patch patch: only one backlight control device under an ACPI video bus device patch: one ACPI video bus device for one VGA controller patch: only one backlight control device under an ACPI video bus device patch for upstream kernel |
||
please attach the full acpidump and dmesg output. (In reply to comment #0) > When the DSDT detects Windows Vista (which Linux seems to pretend to be), it > disables the WMI method and also disables direct control using the hardware > keys, instead expecting software to react to those keypresses and control it > using the ACPI Video device. > what if you boot with acpi_osi="!Windows 2006"? > > The ACPI Video Interface is broken. There are three devices supported: OVGA, > PEGP.EVGA, and PEGP.NVGA. As far as I can tell, OVGA is supposed to be an > integrated graphics controller that doesn't exist. EVGA and NVGA are very > similar and I don't know which one corresponds to my laptop or how the driver > is supposed to tell between them, but clearly one of them is the correct one > and corresponds to the modular MXM card on the laptop. > > OVGA would work except that it corresponds to a nonexistent PCI device, so > acpi_get_physical_pci_device kills it. Hacking this out makes things work > (the > brightness setting is via the EC anyway, and works the same for all three > devices), but that doesn't sound like a good idea. > > EVGA and NVGA fail to register as video devices because they lack the _DOS > method that ACPI specifies as required for backlight functionality. They do > have _DOD, which isn't enough for display output switching support, but at > least identifies them as video devices. They fail the acpi_is_video_device > because that only checks for backlight support if one of the other three > features is fully present. They also fail acpi_video_bus_check because that > again wants one of the three features. > > At this point I'm unsure of what the best way to fix this is. My guess would > be > to make acpi_is_video_device check for brightness controls even if only _DOD > is > present, and also make acpi_video_bus_check consider just _DOD good enough to > pass a device. Then the other issue left would be the duplicated device (the > backlight control is really messed up when it tries to do the same thing to > two > different devices). Applying those two hacks and and manually unbinding one > of > the devices from the driver via sysfs makes things work for me. hah, then this is apperantly a BIOS problem to me because _DOS is mandatory according to the ACPI spec. But anyway, we should make it work in Linux. what about this proposal? 1. acpi_is_video_device returns TRUE if only _DOD in found. 2. print a warning message if there is no _DOS method. 3. don't touch _DOS in ACPI video driver if it's not available. patch will be attached later. Created attachment 22071 [details]
patch: support backlight control without _DOS
please try this patch and see if it helps.
BTW: you should be able to
1. get a warning message in the dmesg output.
2. at least one backlight sysfs I/F should be available.
3. at least one ACPI video bus device should be bind to the video driver.
please attach the
1. dmesg
2. "grep . /proc/acpi/video/*/*"
after applying the patch.
That isn't going to work. Check out acpi_video_bus_check: it returns -ENOENT unless either _DOS, _ROM, or _GPD/_SPD/_VPO are present. Created attachment 22072 [details]
refreshed patch
hah, you're right.
how about this one?
Created attachment 22078 [details]
refreshed patch
Created attachment 22084 [details]
dmesg after patch
As expected, both video devices EVGA and NVGA are detected, so the brightness control "works" but the duplicated device causes erratic behavior when it is used.
$ grep . /proc/acpi/video/*/*
/proc/acpi/video/EVGA/DOS:N/A
/proc/acpi/video/EVGA/info:Switching heads: no
/proc/acpi/video/EVGA/info:Video ROM: no
/proc/acpi/video/EVGA/info:Device to be POSTed on boot: no
/proc/acpi/video/EVGA/POST:<not supported>
/proc/acpi/video/EVGA/POST_info:<not supported>
/proc/acpi/video/EVGA/ROM:<TODO>
/proc/acpi/video/NVGA/DOS:N/A
/proc/acpi/video/NVGA/info:Switching heads: no
/proc/acpi/video/NVGA/info:Video ROM: no
/proc/acpi/video/NVGA/info:Device to be POSTed on boot: no
/proc/acpi/video/NVGA/POST:<not supported>
/proc/acpi/video/NVGA/POST_info:<not supported>
/proc/acpi/video/NVGA/ROM:<TODO>
$ cat /proc/acpi/video/EVGA/LCD/brightness
levels: 10 20 30 40 50 60 70 80 90 100
current: 10
$ cat /proc/acpi/video/NVGA/LCD0/brightness
levels: 10 20 30 40 50 60 70 80 90 100
current: 10
This gets rid of the redundant EVGA device:
$ echo "device:02">/sys/bus/acpi/drivers/video/unbind
and leaves NVGA, making brightness work properly.
Any clue as to what the correct way of picking the right device should be? I think NVGA is correct on my system, and it is also more complete in the DSDT, but I don't get how the software is supposed to pick out which one to enable and use.
well, hard to say which one should be used. Actually they are exactly the same to ACPI, which means that software is not able to pick one and drop another. do you know if there is any newer BIOS available? If no, in order to make the brightness work on this laptop, I think we need to use the dmi quirk. There are no newer BIOSes available. I think that, when the video device is under a parent node with the proper PCI address (as acpi_get_physical_pci_device checks the PEGP device for the address since neither NVGA nor EVGA have real ones), it should only select one of the children, not both. So: when scanning for video devices, if the device _ADR is invalid and the parent device's _ADR is used instead, only accept the first child device. Also, interesting off-topic: I've been extracting and breaking up my BIOS and found that the DSDT in there is actually by Insyde, not Acer, and that the compiler is Intel. The BIOS patches in Acer's name and the "1025" compiler ID at runtime. So this DSDT was in fact compiled by iasl. NVGA and EVGA are independent ACPI devices in this case. It's really ugly to check these two devices and discard the second one neither in ACPI video driver or in ACPI video scan/detect code. I tried, but soon gave up. Because that's not a clean way for this issue neither. Created attachment 22223 [details]
patch: only one backlight control device under an ACPI video bus device
please try this patch and see if it helps.
There's a bug in the patch: the if() should check for !device->video->brightness_dev. Even with that fix, it doesn't seem to work. I still get two video devices with backlight support because they're under different "buses". Also, if I reload the video module, no backlight support is detected because the flag is already set for the bus. Looks like I have further breakage anyway. I'm on 2.6.30-gentoo-r2 now, I'm tracking down some weirdness on the video driver which I think is unrelated. Ok, _BQC is broken on my laptop sometimes (depends on some EC register). I've submitted a patch for that to you via email and CC'd linux-acpi. The duplicated backlight device problem still stands though. well. you're right, I misunderstood the problem. there are two video bus devices under the same pci device node... Created attachment 22347 [details]
patch: one ACPI video bus device for one VGA controller
please try this patch.
That did the trick - it only binds to the first video device (02). The second device reports an error in dmesg though:
video: probe of device:06 failed with error -17
Maybe it should be hidden or turned into a warning ("ignoring duplicate video device" or something similar).
Other than that, everything works now. Good job :)
Created attachment 22351 [details]
patch: only one backlight control device under an ACPI video bus device
this patch should remove the old error message and print a warning message instead.
please give it a try.
this may bring some side effects on the other laptops, but who knows.
I'll send this patch to the ACPI test tree, but not sure it can be merged.
applied to bugzilla-13577-video-TEST in acpi-test tree Please apply attachment 22078 [details] too, both are required for this to work. 22078 makes the two video devices usable, then 22351 disables the redundant one.
you can use http://patchwork.kernel.org/patch/43618/ as a replacement. > you can use http://patchwork.kernel.org/patch/43618/ as a replacement. shipped upstream in 2.6.32-rc5 so do we still need the patches in comment #6 or comment #21? no, the patch in comment #6 is replaced by patch http://patchwork.kernel.org/patch/43618/ the patch in comment #21 is kinda arbitrary. and IMO, a warning message is more acceptable here. please attach the lspci output of your laptop. does the WMI work again if you boot with kernel parameter acpi_osi="!windows 2006"? 2.6.32 appears to work fine. The duplicated backlight device remains, though it does not appear to be causing trouble as far as I can tell. please re-open if there remains an unresolved issue here. Created attachment 24374 [details]
patch for upstream kernel
this is the refreshed patch for upstream kernel, please test it.
commit c504f8cb68eb0d6cde53ba043daff8cb34586493 Author: Zhang Rui <rui.zhang@intel.com> Date: Wed Dec 30 15:59:23 2009 +0800 ACPI video: Prune dupe video devices, unless "video.allow_duplicates" shipped in Linux-2.6.33-rc5 closed |
Created attachment 22005 [details] Disassembled DSDT Backlight controls on this laptop are broken due to a combination of factors. Apparently, the DSDT supports two methods to set the backlight: - old WMI / proprietary method. This is supported by acer_wmi. - ACPI Video interface When the DSDT detects Windows Vista (which Linux seems to pretend to be), it disables the WMI method and also disables direct control using the hardware keys, instead expecting software to react to those keypresses and control it using the ACPI Video device. When I do a very ugly EC hack to turn off Vista mode, acer_wmi works fine to set and query the brightness and also the hardware keys work directly, even without acer_wmi. Presumably this will also be the case if Linux doesn't identify itself as Vista to ACPI. The ACPI Video Interface is broken. There are three devices supported: OVGA, PEGP.EVGA, and PEGP.NVGA. As far as I can tell, OVGA is supposed to be an integrated graphics controller that doesn't exist. EVGA and NVGA are very similar and I don't know which one corresponds to my laptop or how the driver is supposed to tell between them, but clearly one of them is the correct one and corresponds to the modular MXM card on the laptop. OVGA would work except that it corresponds to a nonexistent PCI device, so acpi_get_physical_pci_device kills it. Hacking this out makes things work (the brightness setting is via the EC anyway, and works the same for all three devices), but that doesn't sound like a good idea. EVGA and NVGA fail to register as video devices because they lack the _DOS method that ACPI specifies as required for backlight functionality. They do have _DOD, which isn't enough for display output switching support, but at least identifies them as video devices. They fail the acpi_is_video_device because that only checks for backlight support if one of the other three features is fully present. They also fail acpi_video_bus_check because that again wants one of the three features. At this point I'm unsure of what the best way to fix this is. My guess would be to make acpi_is_video_device check for brightness controls even if only _DOD is present, and also make acpi_video_bus_check consider just _DOD good enough to pass a device. Then the other issue left would be the duplicated device (the backlight control is really messed up when it tries to do the same thing to two different devices). Applying those two hacks and and manually unbinding one of the devices from the driver via sysfs makes things work for me.