[Bugme-new] [Bug 9159] New: Broken video extension (and fixed DSDT) on HP Compaq nc6320

[bugme-daemon at bugzilla.kernel.org]

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: acpi_power-video at kernel-bugs.osdl.org
        ReportedBy: pcjc2 at cam.ac.uk


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 on the CC list for the bug, or are watching someone who is.