Bug 25886 - Xserver wakes itself up shortly after being put to sleep with "xset dpms force off"
Summary: Xserver wakes itself up shortly after being put to sleep with "xset dpms forc...
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-04 05:29 UTC by Chris Rankin
Modified: 2018-06-12 18:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log file (77.70 KB, text/plain)
2010-01-04 05:31 UTC, Chris Rankin
no flags Details
xorg configuration file (3.82 KB, text/plain)
2010-01-04 05:31 UTC, Chris Rankin
no flags Details

Description Chris Rankin 2010-01-04 05:29:26 UTC
Whenever I try to force my monitor into "DPMS off" mode via "xset dpms force
off", it typically wakes itself up again a few seconds later.

This problem only seems to happen with R300 cards and above.

I have a Radeon 9550 card, connected via a DVI cable. The monitor is at
1680x1050 resolution, 24 bit depth.

See RedHat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=524360
Comment 1 Chris Rankin 2010-01-04 05:31:14 UTC
Created attachment 32432 [details]
Xorg log file
Comment 2 Chris Rankin 2010-01-04 05:31:47 UTC
Created attachment 32433 [details]
xorg configuration file
Comment 3 Alex Deucher 2010-01-04 06:54:55 UTC
This is not a driver bug.  It is caused by late input events.  try:
sleep 5; xset dpms force off
to make sure all input events have been processed before the monitor is turned off.
Comment 4 Chris Rankin 2010-01-04 08:17:08 UTC
(In reply to comment #3)
> This is not a driver bug.  It is caused by late input events.

Is there a way to see what these "input events" actually are? Because if they can be *this* late then I would consider that to be a bug in its own right. (Had you suggested that invisible pixies were dancing on the keyboard, I would have been only *slightly* more surprised by your response.)

The X server certainly never used to behave this way.
Comment 5 Michel Dänzer 2010-01-04 08:25:08 UTC
(In reply to comment #4)
> Is there a way to see what these "input events" actually are? Because if they
> can be *this* late then I would consider that to be a bug in its own right.

No, usually it's simply the key up event from releasing the enter key. The command can easily be executed faster than a human being can release the key.
Comment 6 Chris Rankin 2010-01-04 08:41:55 UTC
(In reply to comment #5)
> No, usually it's simply the key up event from releasing the enter key. The
> command can easily be executed faster than a human being can release the key.

Except that the time interval between my pressing Enter and the X server waking up again is of the order of 10 - 20 seconds. That's too large for me to believe that it's the release Event. If that were the case, I would expect it to wake up immediately.

Comment 7 Chris Rankin 2010-01-04 11:13:24 UTC
(In reply to comment #5)
> No, usually it's simply the key up event from releasing the enter key. The
> command can easily be executed faster than a human being can release the key.

I have just retested this with both the following commands:

sleep 5; xset dpms force off
sleep 10; xset dpms force off

And in both cases, the machine still *always* wakes itself up.

Comment 8 Alex Deucher 2010-01-04 11:19:15 UTC
Might be an acpi event or something like that.  Either way, this isn't a driver bug.
Comment 9 Chris Rankin 2010-01-04 11:29:26 UTC
(In reply to comment #8)
> Might be an acpi event or something like that.  Either way, this isn't a driver
> bug.

How do we ask the driver what is waking it up, then?
Comment 10 Alex Deucher 2010-01-04 13:06:04 UTC
The driver provides a dpms hook that the X server uses.
Comment 11 Adam Jackson 2018-06-12 18:44:04 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.


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.