| Summary: | All ACPI events interpreted as input, breaking DPMS / input timeouts | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Kevin Shanahan <kevin> |
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | danielle, esigra, mitch, mlists, ninex, shrek |
| Version: | 6.9.0 | Keywords: | regression |
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| URL: | http://lists.freedesktop.org/archives/xorg/2006-January/012304.html | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 6666 | ||
|
Description
Kevin Shanahan
2006-01-20 13:25:58 UTC
Please note these suggestions and tests already carried out: http://lists.freedesktop.org/archives/xorg/2006-January/012313.html Okay, Felix says it looks like a driver bug, so reassigning to componenet Driver/Radeon. - http://lists.freedesktop.org/archives/xorg/2006-January/012446.html It could be a battery acpi event or a laptop specific bios event. I've heard of some users that had this sort of thing wake their PCs. I can see this coming up regularly in acpid.log: [Thu Jan 26 07:53:54 2006] received event "battery BAT1 00000080 00000001" [Thu Jan 26 07:53:54 2006] notifying client 3267[0:0] [Thu Jan 26 07:53:54 2006] completed event "battery BAT1 00000080 00000001" Could this be causing X to wake up the screen for any reason? As I say, the problem doesn't occur with xorg-6.8.2 so something must have changed. If I start the server from the console using "startx -- -noacpi" DPMS works again (the screen stays switched off when I ask it to). The only events showed when I run acpi_listen are the battery events. According to xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_acpi.c all events that don't start with "video" should be getting ignored. Hopefully I'm looking in the right place, but I'm going to start inserting some debug statements to learn what's going on. Any tips appreciated. Okay, I've now narrowed it down to the call to DPMSSet in xc/programs/Xserver/os/WaitFor.c. For some reason, the acpi battery events are causing this to trigger. At this stage I'm getting out of my depth and need some help... Okay, maybe I see now what's going on. In xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_acpi.c::lnxACPIOpen, the ACPI socket fd is registered as an input handler. When we're in WaitForSomething, this fd will become readable, and immediately the DPMSSet() call is made. There is no opportunity to see if the event handler (xf86HandlePMEvents) is going to discard the event or not (as it would for a battery event). So with the current structure, a battery status change registers as an input event, screwing with DPMS. I think that establishes well enought that it's not a Radeon bug, so I'm going to change the component to Server/general and re-title to something perhaps more descriptive of the underlying problem. P.s. I'm seeing this on nvidia using the free 'nv' driver also on my Toshiba tecra M2. I think you're right this is not a radeon specific issue *** Bug 6931 has been marked as a duplicate of this bug. *** *** Bug 7264 has been marked as a duplicate of this bug. *** I think Kevin's analysis in comment #7 is correct. This is definitely a release blocker for 7.2. we have AddGeneralSocket() now in master; it's a pretty simple change. fixed in master Could someone please take a look at Gentoo bug #150028 [http://bugs.gentoo.org/show_bug.cgi?id=150028] and tell if this is the same problem? (In reply to comment #14) > Could someone please take a look at Gentoo bug #150028 > [http://bugs.gentoo.org/show_bug.cgi?id=150028] and tell if this is the same > problem? > yes it's the same bug This might still be broken after a suspend/resume (S3). Yeah, this is fixed just as long as you don't suspend/resume your machine. When you first power up, things are fine, after you come back from an S3 resume the LCD refuses to go to sleep. obviously it's not adding the acpi pipe as an input handler after (but only after) s3, and adding it as a general handler before s3: you've encountered another bug. please open a new one on whichever driver you use, attaching xorg.0.log and xorg.conf. Ok. Filed as bug #10565 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.