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