Bug 198307

[adding Richard Hughes, g-p-m maintainer to this bug]

Hi, so, gnome-power-manager uses DPMS to turn off the backlight. 

It would be very useful if there was a "turn off backlight and make it stay off"
interface in the X server that g-p-m could use. Surely, the X server would have
to track the connection so the backlight comes on again if the X11 client using
this option would disconnect, e.g. should g-p-m crash.

Is it a good idea; can we add this please?

Actually, it seems worse than this.  If I close the lid and the backlight goes
off I don't even have to wait for a power change to trigger the backlight to
come on.  It appears that any drawing to the display causes the backlight to
come back on?  That's just a guess but I only have to wait a few seconds for
some random event to kick the display back on.

But changing the power settings definitely cause the display to come on every
time.  Maybe it's the drawing of the notification bubble that's causing it?

OK, David figured this out.  What's happening is that X is disabling the
backlight when the lid is closed.  However, the backlight is turned back on
whenever there's an input event.  So I can reproduceably move my external mouse
and the backlight will come on when the lid is closed.

David suggests that the X server might want to poll this file:

/proc/acpi/button/lid/LID0/state

for "state: closed"

The thinkpads apparently disconnect power to the back light when you close the
lid.  The macs don't.

At least you want to check that file (/proc/acpi/button/lid/LID0/state) before
enabling backlight again. Also, ideally you want to connect to acpid for async
delivery of ACPI events and turn it off backlight when the lid is closed.

You also want to be careful to only do this if you are 100% sure that the
monitor you are controlling is actually the screen on the laptop lid. For
example, many people wants to be able to close the lid of their laptops and use
the external monitor. But you probably already know this.

(In reply to comment #1)
> It would be very useful if there was a "turn off backlight and make it stay off"
> interface in the X server that g-p-m could use. Surely, the X server would have
> to track the connection so the backlight comes on again if the X11 client using
> this option would disconnect, e.g. should g-p-m crash.

Surely this is the proper fix rather than getting X to poll a file?

(In reply to comment #1)

> It would be very useful if there was a "turn off backlight and make it stay off"
> interface in the X server that g-p-m could use. Surely, the X server would have
> to track the connection so the backlight comes on again if the X11 client using
> this option would disconnect, e.g. should g-p-m crash.

No, bad idea, X server has no way of knowing which applications should be
allowed to do this (g-p-m) and which should not (firefox).  I'd rather just
teach the server about lid status.

(In reply to comment #6)

> No, bad idea, X server has no way of knowing which applications
> should be allowed to do this (g-p-m) and which should not (firefox). 

By the same token no server configuration (e.g. xrandr) should be allowed via
the X11 protocol :-) 

[insert pitch about making the X.org server configurable via out-of-band D-BUS
interfaces instead]

> I'd rather just teach the server about lid status.

Sure, that's probably the better choice anyway.

Btw, make sure you don't rely on ACPI events being delivered via acpid because
some ACPI stacks are broken and they don't deliver it on e.g. resume via lid
open - we've certainly had our share of fun in that with hal / g-p-m. Polling
the file once in a while to check the status should cover your ass.

Also watch out for new ACPI interfaces appearing in future - not sure how long
the /proc/acpi crap will stick around though I fear it will be there for at
least the 2.6 timeframe.

Thanks for looking into this. Appreciated.

It turns out it's worse than this.  The ACPI event channel is treated as an
input device; any input event will wake up the screen.

That's asstastic.

Confirmed on my x86-64 HP L2000. The screen gets woken up on average in less
than 10 seconds.

So, is there any way we can get X to ignore certain input events?

Still the case with fc7test1 and above, and as it's not driver-specific I'm
changing the affected component to xorg-x11. Hopefully this can be fixed by
Fedora 7's release date?

Not sure why this is assigned to me. Reassigning to owner.

sorry for confusion.

Moving to 'devel' as discussed on
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00095.html.

This should be reasonably straightforward to do with Linux 2.6.20 as ACPI lid
button is a real input device (alternatively use HAL if you're not afraid of a
D-Bus dependency)

 1) find the right input device in /sys/class/input/input%d by looking
    at capabilities/* (look for SW_LID set in sw being the only cap) and 
    id/bustype (look for BUS_HOST) 

 2) use udevinfo(8) to get the device file name (there's one and only
    and event%d subdirectory so pick the right one)

    $ udevinfo --query name --path=/sys/class/input/input9/event9 --root
      /dev/input/event9

 3) check the state with the EVIOCGSW ioctl

 4) poll() the associated device file  for change notification

 5) profit

Seriously, my Macbook Pro almost melted today because of this bug. It would be
nice to fix this. Thanks.

Yeah, but this ought to be working _anyway_.  We're using the general fd handler
now, which doesn't get treated as an input device.  Assuming we're still running
acpid anyway...

I can't repro this on a fujitsu lifebook, so I'm a bit at a loss if it's still
an issue, and I'll need to find a machine where it _is_ happening.

Just a note -- could it be related to
https://bugs.freedesktop.org/show_bug.cgi?id=11527 ??

It might be, but I thought the mbp was an ATI chip.

I still haven't been able to repro this on any of my laptops.

User blizzard's account has been closed

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp