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.

Brice

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).

Hello Tim,

Two years ago you submitted this bug against xserver-xorg-core:
Does this still occur with more recent packages, if not can you tell me
the version you are using so I can close the bug.

Also for the nvidia driver, you might want to test nouveau.

Best Regards,

If acpi-support is set to use xrandr rather than xset, then it looks
like it will work for drivers that have the LVDS output hooked up to the
internal display, as lid close runs "xrandr --output LVDS --off".  All
other choices ("xset" and "vbetool") turn off both displays.  And of
course, this all only works on the display ":0", but most people won't be
running X on other displays as well.

nvidia doesn't have this (using their crappy non-xrandr enabled "twinview"
thing instead), but that's not really Debian's problem.  I don't know
whether the nv or nouveau drivers have an "LVDS" xrandr output.

It has been the case that acpi-support can be configured to use xrandr
since at least acpi-support version: 0.132-1.

It still would be a lot nicer if xorg intercepted the power management
event instead of acpi-support (since xorg already intercepts some sort of
power management events according to Xorg.log) and turns on and off the
internal display directly without the help of acpi-support, and that way
it could turn off the correct display without fudging about.  Note also
that vbetool is the only available method to turn off the backlight when
not using X.