Since the recent changes in acpi's video.ko: commit a21101c46ca5b4320e31408853cdcbf7cb1ce4ed http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=a21101c46ca5b4320e31408853cdcbf7cb1ce4ed A nasty series of bugs has been exposed in the DSDT for this laptop. For the kernel I was using when I tested this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commit;h=0080187b6cc12926ab25e06347ae9adec27e5507 it appears that the video.ko has its _DOS settngs around the wrong way, so loading video.ko allowed the BIOS to poke the settings, and removing video.ko prevented the BIOS from poking the settings. (This seems reversed... we want Linux to handle the changes, and the BIOS to keep hands off when video.ko loads, and presumably revert back to the BIOS poking the settings when we unload video.ko). I reversed the sense of the acpi_video_bus_DOS() calls when testing, which seemed to help this there. I call acpi_video_bus_DOS(video, 0, 1) when the device is started and call acpi_video_bus_DOS(video, 1, 0) when the device is removed. There is unfortunately DSDT brokenness which means it still doesn't work satisfactorily, but I debugged this with a DSDT override. The symptom was getting a lid notification, but there would be a long delay before /proc/acpi/button/lid/*/state "caught up". That breaks userspace that checks this state when it sees an event. This delay was due to various sleep statements in the DSDT when not internally handling the backlight etc.. There are also a lot of OS specific paths in the DSDT for this code, making things even more fun to trace. The results of my debugging........ Once video.ko executes the _DOS method, the laptop's AML deprograms the bit in the ICH7 GPIO interrupt routing control register corresponding to lid control, so lid events no longer get to userspace (apart from if you plug / unplug the AC adaptor - which seems to cause the register to be reprogrammed). In addition to this (having poked the GPIO interrupt register back manually / overridden the AML code), there is a problem with long Sleep() delays in the GPIO handlers. The lid handler issues a Notify event on the button device as it is pressed, then some other notifies on the Video device (to check output devices?) - however the response of the _LID method is not updated until those notifications and sleeps have completed. User space (on seeing the button Notify event) immediately checks the result of evaluating _LID, which thanks to the delays will return the wrong status, and causing breakage. Also: the bios isn't honouring the _DOS request not to change brightness when plugging / unplugging the AC adaptor. Also: The _BQC method is mis-named in the AML as _BCQ, causing brightness changes not to work correctly in non-bios managed mode. I'm told that the prospect of a BIOS update to fix this is remote, as its an old platform (my laptop is 1yr old). It also seems there isn't a lot we can do to fix it within Linux without a DSDT override, and even then I can't see how we can stop the backlight changes when the AC is plugged / unplugged (that doesn't seem to be implemented in the DSDT). It is possible (I know which registers) to read the lid status straight out of the ICH7 chip GPIO registers, however this is a little bit hardware specific ;)
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. :)