[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#466044: xserver-xorg-core: internal screen of laptop with external screen attached not blanked when laptop closed but still in use



On Mon, 10 Mar 2008, Brice Goglin wrote:

> On Sat, Feb 16, 2008 at 06:28:52PM +1100, Tim Connors wrote:
> > Package: xserver-xorg-core
> > Version: 2:1.4.1~git20080131-1
> > Severity: normal
> >
> > Laptop screens backlights are turned off these days by getting acpi to
> > intercept the lid button, and it runs xset to force the display off
> > via 'xset dpms force off' (after a series of other attempts at locking
> > the display etc, which are all equally invalid in the circumstances I
> > outline below).  This is a rather course control, and just turns off
> > the backlights of all attached screens.
> >
> > My old laptop, when it was running APM, controlled the backlight
> > itself, and it worked well such that you could close the laptop and it
> > would turn off the interal display, but leave the external display
> > turned on.  DPMS would then turn off the external display when it was
> > left alone, and when the display was woken up again, only the external
> > display was woken up - the internal one was left undisturbed until the
> > screen was opened again.  This is not bug 466042, where the internal
> > display is turned on and off via dpms, but the external display is let
> > alone.  In the circumstances in that bug, the internal display should
> > be completely ignored.  The lid switch would have no effect on the
> > external display (but xset dpms would still work on it) or the
> > internal display (because the resolution is wrong), if both this and
> > bug 466042 were fixed.
> >
> > I think the lid button should be intercepted by X itself, rather than
> > handing the functionality off to acpid, which then runs 'xset dpms
> > force off'.  This way you can close the laptop screen, which would
> > shut off the backlight to the internal display.  And DPMS timeouts or
> > running 'xset dpms force off' would turn off both displays.  Pressing
> > a key when DPMS was on would only turn on the external display unless
> > the screen was open, in which case the internal display would be
> > turned on too.  In other words, the internal backlight being
> > controlled by the lid switch has absolutely nothing to do with dpms.
>
> Please try with the nv driver (or any other free driver) instead of
> nvidia and see whether upgrading nvidia-glx to the latest helps.

Well, acpid does the blanking (which would of course mean that any fix to
this bug would require the cooperation of the acpi maintainers, and X
maintainer.  As I said, closing the internal screen should not touch DPMS,
by acpi or otherwise.  It should turn the internal backlight off, only, by
some other means).

Nevertheless, I tested this with nv, and disabled all dpms related stuff
in /etc/acpi/.  As expected, the internal backlight on the laptop remains
on when the screen is shut.  If /etc/acpi/ is reenabled, then of course
both screens turn off, because `xset dpms force off` is run.

I shall test this on my other laptop with completely different driver
(r128), for completeness, when I get home next week.  But it's got other
dpms related bugs involving the external screen (bug #466042) which will
probably make it hard to test properly (since I won't know whether it is
trying to blank the screen via DPMS, because the external monitor will
remain on regardless).

-- 
TimC
Theoretically one might have been wearing pants at work.
        -- Anthony de Boer in Scary Devil Monastry



Reply to: