Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 198307
Summary: | backlight is enabled at any DPMS event | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Brian Stevens <bstevens> |
Component: | xorg-x11-server | Assignee: | Adam Jackson <ajax> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | davidz, mcepl, michel.salim, richard, tmraz, triage |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-07 00:35:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 199990 |
Description
Christopher Blizzard
2006-07-10 23:48:01 UTC
[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 |