Bug 198307 - backlight is enabled at any DPMS event
backlight is enabled at any DPMS event
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
David Lawrence
bzcl34nup
:
Depends On:
Blocks: 199990
  Show dependency treegraph
 
Reported: 2006-07-10 19:48 EDT by Brian Stevens
Modified: 2014-09-08 20:40 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:35:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 5665 None None None Never

  None (edit)
Description Christopher Blizzard 2006-07-10 19:48:01 EDT
Description of problem:

If the lid on my 2006 MacBook is closed and the backlight is off, any change in
the status of the power will cause the backlight to come on - even if the laptop
lid is still closed.

Version-Release number of selected component (if applicable):

kernel-2.6.17-1.2358.fc6
xorg-x11-server-Xorg-1.1.0-27.fc6
gnome-power-manager-2.15.3-1

How reproducible:

Every time.

Steps to Reproduce:
1. Close the lid with the power connector connected.  Backlight goes off.
2. Unplug the power.  The backlight comes on, even with the lid closed.

(Same happens if you close it with the power disconnected.  Plug it in and the
backlight comes on.)
  
Actual results:

Backlight is activated and laptop starts getting...very warm.

Expected results:

Backlight stays off when the lid is closed.

Additional info:

I think this happens when you get the "battery full" message as well.  I've come
out in the morning and the backlight is on after leaving the laptop plugged in
and charging.

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express
Integrated Graphics Controller (rev 03)

That's the video chip.
Comment 1 David Zeuthen 2006-07-11 13:39:00 EDT
[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?
Comment 2 Christopher Blizzard 2006-07-12 23:07:04 EDT
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?
Comment 3 Christopher Blizzard 2006-07-27 13:51:02 EDT
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.
Comment 4 David Zeuthen 2006-07-27 14:28:43 EDT
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.
Comment 5 Richard Hughes 2006-07-28 15:26:42 EDT
(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?
Comment 6 Adam Jackson 2006-08-04 19:05:26 EDT
(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.
Comment 7 David Zeuthen 2006-08-04 19:15:40 EDT
(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.
Comment 8 Adam Jackson 2006-10-03 11:11:10 EDT
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.
Comment 9 Christopher Blizzard 2006-10-03 11:55:39 EDT
That's asstastic.
Comment 10 Michel Alexandre Salim 2006-10-19 19:18:58 EDT
Confirmed on my x86-64 HP L2000. The screen gets woken up on average in less
than 10 seconds.
Comment 11 Richard Hughes 2006-10-22 12:58:02 EDT
So, is there any way we can get X to ignore certain input events?
Comment 12 Michel Alexandre Salim 2007-02-15 03:21:39 EST
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?
Comment 13 David Zeuthen 2007-02-15 11:32:34 EST
Not sure why this is assigned to me. Reassigning to owner.
Comment 14 Matěj Cepl 2007-02-15 12:58:40 EST
sorry for confusion.
Comment 15 Bill Nottingham 2007-03-02 12:34:16 EST
Moving to 'devel' as discussed on
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00095.html.
Comment 16 David Zeuthen 2007-03-04 23:13:03 EST
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.
Comment 17 Adam Jackson 2007-04-10 18:07:01 EDT
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.
Comment 18 Matěj Cepl 2007-07-12 12:00:35 EDT
Just a note -- could it be related to
https://bugs.freedesktop.org/show_bug.cgi?id=11527 ??
Comment 19 Adam Jackson 2007-07-12 16:06:02 EDT
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.
Comment 20 Red Hat Bugzilla 2007-10-21 20:43:35 EDT
User blizzard@redhat.com's account has been closed
Comment 21 Bug Zapper 2008-04-03 13:36:20 EDT
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.
Comment 22 Bug Zapper 2008-05-06 20:35:37 EDT
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

Note You need to log in before you can comment on or make changes to this bug.