http://bugzilla.kernel.org/show_bug.cgi?id=9159
Summary: Broken video extension (and fixed DSDT) on HP Compaq nc6320 Product: ACPI Version: 2.5 KernelVersion: 2.6.22-14-generic (Ubuntu) Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Power-Video AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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 ;) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla