Bug 9159
Summary: | Broken video extension (and fixed DSDT) on HP Compaq nc6320 | ||
---|---|---|---|
Product: | ACPI | Reporter: | Peter Clifton (pcjc2) |
Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.22-14-generic (Ubuntu) | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump output
My fixed DSDT (removed lots of WMI cruft too) |
Description
Peter Clifton
2007-10-13 12:11:17 UTC
Created attachment 13146 [details]
acpidump output
acpidump output from the laptop's firmware (latest BIOS available)
Created attachment 13147 [details]
My fixed DSDT (removed lots of WMI cruft too)
Here is a DSDT which I was using to debug the issue. Its removed the offending Sleep commands HP added to keep windows happy. Now the _LID command returns the right status by the time userspace queries it.
I've also stopped them de-programming the lid GPIO interrupt routing. I'm told this was done because Windows only ever asks the laptop to _completely ignore_ the video switching events (_DOS invoked with 2?).
I renamed the brightness query function to be correct, and that make brightness controls in userspace work. (They previously worked fine via the BIOS).
Sorry, it appears that it wasn't the change in a21101c46ca5b4320e31408853cdcbf7cb1ce4ed at all, there was an Ubuntu change which stops video.ko making changes by default (letting userspace have them instead), and this got me debugging when the userspace choked on the broken _LID status it was seeing. The comments about the brokenness of the DSDT and the laptop's not honouring the _DOS bit which stops adjusting brightness on AC / battery still stand. >Windows only ever asks the laptop to _completely ignore_ the video switching
>events
Then how it gets notified when display-switch hotkey is pressed by users? :(
I agree that we should call acpi_video_bus_DOS(video, 0, 1) when acpi video driver is loaded and call acpi_video_bus_DOS(video, 1, 0) when it's unloaded.
But this changes the behaviour of all the Linux laptop, we must be careful if we want to push it upstream. :)
For the other problems, they seem to be bios bugs rather than linux/acpi problems, did you check for any bios update? did you contact HP for a bios fix?
I will try Windows when I get chance, and see how it behaves. There might be a specific driver, but this is just speculation. No BIOS update available, and no prospect of one. I've been in touch with HP via support channels (no response), and more indirectly to someone in their BIOS team who did confirm some of my findings. On this platform, the brightness is controlled in an SMI on the AC/DC change. I am not aware of anyway to disable/bypass this. [snip] The long delays have been necessary for lid functionality to work under the Microsoft OS's and Intel video drivers. The first OS to use _BQC (that I am away of) was Vista and this product shipped before that OS was available so the method could not be tested. Also, no OS had actually implemented the _DOS brightness bit when this product shipped. This is not a current platform so I doubt that much can be done to correct these issues. There are quite a lot of changes in video driver. It would be greate if you can update the info in the latest kernel release. Close this bug due to no response from the bug reporter. Please re-open it if you have some question. :) |