Laptop screen doesn't come on when lid is reopened

Laptop screen doesn't come on when lid is reopened

[Daniel Drake]

Hi,

Like many Dell's, my Inspiron 640m turns off the LCD display when the 
lid is closed, but doesn't power it back up when the lid is opened.

This has been discussed before, with the conclusion that it's a BIOS bug 
which Linux can't fix (i.e. including a link in the kernel from ACPI to 
video isn't practical). However I'd like to revisit this as I believe 
I've found some information which wasn't discussed/observed before:

The lid notification method can be seen here: 
http://bugzilla.kernel.org/show_bug.cgi?id=5155#c6

Of specific interest, the lid notification comes with video 
notifications - the DSDT seems to be expecting the OS to do something 
with the video hardware.

I dug further and found that the first Store in that method is what 
turns the display off, and the following If always triggers (for both 
open and close events) in my testing. Sidenote: this means that the DSDT 
turns the display off both on close and on open.

I also found that no link to the video layer of the kernel would be 
needed to restore the display here: the _DSS method of the LCD device 
will happily turn the display back on.

I fixed my DSDT with this modification:

      Method (LIDE, 0, NotSerialized)
      {
+        // If lid open, enable video
+        If (LNotEqual(\_SB.LID._LID(), 0)) {
+            \_SB.PCI0.VID.LCD._DSS(0x80000001)
+            Notify (\_SB.LID, 0x80)
+            Return
+        }
+
+        // If lid closed, continue
+
+        // The following Store turns the LCD off
          Store (SMI (0x43, 0x00), Local0)
          If (LAnd (LNotEqual (Local0, 0x00), LNotEqual (Local0, 0x0F)))

Works nicely, woohoo!

I'd now like to investigate moving this modification into the kernel so 
that no DSDT changes are required. I'm running into some problems here:

If I create an acpi_driver alongside the button driver, the button 
driver claims the lid and my driver doesn't. I presume this is by design 
-- I was hoping that he subsystem would allow 2 drivers to work on the 
same device.

I then tried creating a new module which would use acpi_get_handle() to 
find the lid handle, and then acpi_install_notify_handler() to set up an 
event handler. I was hoping that the subsystem would allow multiple 
handlers on one event, but it appears I'm out of luck again: While the 
button driver is loaded and subscribed to this event, my driver gets the 
AE_ALREADY_EXISTS error code.

Are there other approaches I can take here? I'm hoping to create some 
kind of "Dell extras" driver, which contains a list of buggy systems, 
and listens for the lid events. When it detects a lid open event, it 
will call _DSS on the LCD device.

Thanks,
Daniel

Re: Laptop screen doesn't come on when lid is reopened

[Len Brown]

On Sunday 06 May 2007 16:17, Daniel Drake wrote:
> Hi,
> 
> Like many Dell's, my Inspiron 640m turns off the LCD display when the 
> lid is closed, but doesn't power it back up when the lid is opened.
> 
> This has been discussed before, with the conclusion that it's a BIOS bug 
> which Linux can't fix (i.e. including a link in the kernel from ACPI to 
> video isn't practical). However I'd like to revisit this as I believe 
> I've found some information which wasn't discussed/observed before:
> 
> The lid notification method can be seen here: 
> http://bugzilla.kernel.org/show_bug.cgi?id=5155#c6
> 
> Of specific interest, the lid notification comes with video 
> notifications - the DSDT seems to be expecting the OS to do something 
> with the video hardware.
> 
> I dug further and found that the first Store in that method is what 
> turns the display off, and the following If always triggers (for both 
> open and close events) in my testing. Sidenote: this means that the DSDT 
> turns the display off both on close and on open.
> 
> I also found that no link to the video layer of the kernel would be 
> needed to restore the display here: the _DSS method of the LCD device 
> will happily turn the display back on.
> 
> I fixed my DSDT with this modification:
> 
>       Method (LIDE, 0, NotSerialized)
>       {
> +        // If lid open, enable video
> +        If (LNotEqual(\_SB.LID._LID(), 0)) {
> +            \_SB.PCI0.VID.LCD._DSS(0x80000001)
> +            Notify (\_SB.LID, 0x80)
> +            Return
> +        }
> +
> +        // If lid closed, continue
> +
> +        // The following Store turns the LCD off
>           Store (SMI (0x43, 0x00), Local0)
>           If (LAnd (LNotEqual (Local0, 0x00), LNotEqual (Local0, 0x0F)))
> 
> Works nicely, woohoo!
> 
> I'd now like to investigate moving this modification into the kernel so 
> that no DSDT changes are required. I'm running into some problems here:
> 
> If I create an acpi_driver alongside the button driver, the button 
> driver claims the lid and my driver doesn't. I presume this is by design 
> -- I was hoping that he subsystem would allow 2 drivers to work on the 
> same device.
> 
> I then tried creating a new module which would use acpi_get_handle() to 
> find the lid handle, and then acpi_install_notify_handler() to set up an 
> event handler. I was hoping that the subsystem would allow multiple 
> handlers on one event, but it appears I'm out of luck again: While the 
> button driver is loaded and subscribed to this event, my driver gets the 
> AE_ALREADY_EXISTS error code.
> 
> Are there other approaches I can take here? I'm hoping to create some 
> kind of "Dell extras" driver, which contains a list of buggy systems, 
> and listens for the lid events. When it detects a lid open event, it 
> will call _DSS on the LCD device.

First the generic acpi video driver needs to be enhanced
to support the ACPI display switching features.
Luming has posed patches along these lines already.

Then we should use that to discover if invoking _DSS
fixes more machines than this pair of Dell laptops,
and if it causes any others to break.

Assuming that it works on the Dells, hopefully more
than the Dells, and doesn't break any others...

Then the button driver should take the lid event and
cause the code in the video driver to be invoked.
I'm not sure what the best method for inter-driver
event like this, since both of them can be modules.

Finally, the video driver should have suspend/resume methods
that poke _DSS and that should fix the Dell video on S3.

-Len

Re: Laptop screen doesn't come on when lid is reopened

[Henrique de Moraes Holschuh]

On Wed, 09 May 2007, Len Brown wrote:
> Assuming that it works on the Dells, hopefully more
> than the Dells, and doesn't break any others...
...
> Then the button driver should take the lid event and
> cause the code in the video driver to be invoked.
> I'm not sure what the best method for inter-driver
> event like this, since both of them can be modules.

It will break all laptops which don't do anything special on lid events
other than report it to the OS, so that we can do whatever we want
(typically tell HAL or some script to suspend if the lid is closed).  Like,
say, thinkpads.

> Finally, the video driver should have suspend/resume methods
> that poke _DSS and that should fix the Dell video on S3.

Yes, that seems like a good idea.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Laptop screen doesn't come on when lid is reopened

[Matthew Garrett]

On Wed, May 09, 2007 at 07:00:07PM -0300, Henrique de Moraes Holschuh wrote:

> It will break all laptops which don't do anything special on lid events
> other than report it to the OS, so that we can do whatever we want
> (typically tell HAL or some script to suspend if the lid is closed).  Like,
> say, thinkpads.

Why would it do that? The obvious risk is that calling _DSS would break 
things, but I haven't seen that on Thinkpads. I don't think Len's 
proposing not passing the lid event through to userspace as well.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Laptop screen doesn't come on when lid is reopened

[Henrique de Moraes Holschuh]

On Wed, 09 May 2007, Matthew Garrett wrote:
> On Wed, May 09, 2007 at 07:00:07PM -0300, Henrique de Moraes Holschuh wrote:
> > It will break all laptops which don't do anything special on lid events
> > other than report it to the OS, so that we can do whatever we want
> > (typically tell HAL or some script to suspend if the lid is closed).  Like,
> > say, thinkpads.
> 
> Why would it do that? The obvious risk is that calling _DSS would break 

I was not talking about calling _DSS per se, but calling it when you get lid
events.  Nevertheless, it was actually a big thinko.  It probably won't
break anything, as you said.  Sorry about that.

And, if it is actually needed to turn the backlight back on when you press
the lid *without triggering a suspend*, then it is probably going to be
necessary.

> things, but I haven't seen that on Thinkpads. I don't think Len's 
> proposing not passing the lid event through to userspace as well.

Correct.  As I said, it was a thinko on my part.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Laptop screen doesn't come on when lid is reopened

[Daniel Drake]

Len Brown wrote:
> Then the button driver should take the lid event and
> cause the code in the video driver to be invoked.
> I'm not sure what the best method for inter-driver
> event like this, since both of them can be modules.

I have taken a stab at this approach and it is working nicely. I'm 
sending patches to the linux-acpi list shortly.

Daniel