Bug 6502 - Can't switch resolution via XRandR after some time
Summary: Can't switch resolution via XRandR after some time
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Keywords: patch
Depends on:
Blocks: xorg-7.3
  Show dependency treegraph
Reported: 2006-04-05 20:57 UTC by Daniel Stodden
Modified: 2007-09-04 13:37 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Xorg.0.log -- MergedFB off (45.23 KB, text/plain)
2006-05-09 20:47 UTC, Daniel Stodden
no flags Details
Xorg.0.log -- MergedFB on (57.80 KB, text/plain)
2006-05-09 20:48 UTC, Daniel Stodden
no flags Details
Brian Wallis's xorg.conf file (7.90 KB, text/plain)
2006-08-07 22:38 UTC, Brian Wallis
no flags Details
strace from running xrandr -s 1 (8.42 KB, text/plain)
2006-08-07 22:41 UTC, Brian Wallis
no flags Details
strace of xrandr -o left before date change -> rotation working (9.39 KB, text/plain)
2007-01-03 15:23 UTC, Heiko Baumann
no flags Details
strace of xrandr -o left after date change -> rotation not working (9.23 KB, text/plain)
2007-01-03 15:24 UTC, Heiko Baumann
no flags Details
add debugging prints to the randr extension on the server side (775 bytes, patch)
2007-02-02 13:56 UTC, Marius Gedminas
no flags Details | Splinter Review
proposed fix (1.20 KB, patch)
2007-02-02 14:34 UTC, Marius Gedminas
no flags Details | Splinter Review
Previous patch updated for Fedora 7's xorg-x11-server-Xorg- (1.09 KB, patch)
2007-08-12 20:03 UTC, Dale Sedivec
no flags Details | Splinter Review

Description Daniel Stodden 2006-04-05 20:57:50 UTC
Thinkpad T41,
0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL
Mobility T2] (rev 80)

Recently upgraded from 6.8 (Ubuntu Linux, breezy) to 7.0 (dapper).

Every once in a while, suspend-to-ram seems to disable video mode switching
after resume. Not deterministically, as it appears, but chances above 50%.

Reporting of video modes continues to work. Screen modes are shown below.
Attempting to switch modes per CLI terminates without errors, but shows no
reaction (none, nada) on behalf of the server. No server log output.

The problem appeared with the switch to 7.0. Xorg 6.8 did not expose that
behavior. I've upgraded to radeon_drv from CVS as of 2005-04-05 to see whether
that fixes the issue [congratulations for the new build system, it's a huge
improvement over imake], but with no improvement.
 SZ:    Pixels          Physical       Refresh
*0   1600 x 1200   ( 542mm x 406mm )  *-19187
 1   1400 x 1050   ( 542mm x 406mm )   12572
 2   1024 x 768    ( 542mm x 406mm )   12572
 3    800 x 600    ( 542mm x 406mm )   12567
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
Comment 1 Erik Andren 2006-04-06 07:07:27 UTC
Could you please provide a strace log using xrandr when it works / doesn't work?
Comment 2 Michel Dänzer 2006-05-08 20:51:48 UTC
Does xrandr also display such weird refresh rates when it's working? If so, this
might be related to bug 6421.
Comment 3 Daniel Stodden 2006-05-08 23:07:49 UTC
(In reply to comment #2)
> Does xrandr also display such weird refresh rates when it's working? If so, this
> might be related to bug 6421.

ah, yessssir. 

xvidtune claims 0.2 petahertz for 1600x1200.

a second note: after playing around with xrandr for a few more tries, i found
that the original summary claiming that xrandr ceasing operations ist linked to
resume from standby being a misinterpretation.

suspend/resume seems to enforce that state to some degree. but i found it breaks
anyway just after running the server for some time.

Comment 4 Michel Dänzer 2006-05-08 23:18:30 UTC
So, does it also happen if you disable MergedFB? Is there anything interesting
in the log file?
Comment 5 Daniel Stodden 2006-05-09 20:47:06 UTC
Created attachment 5577 [details]
Xorg.0.log -- MergedFB off
Comment 6 Daniel Stodden 2006-05-09 20:48:08 UTC
Created attachment 5578 [details]
Xorg.0.log -- MergedFB on
Comment 7 Daniel Stodden 2006-05-09 20:49:13 UTC
(In reply to comment #4)
> So, does it also happen if you disable MergedFB? 

ahem, the merits of mergedFB are one of those options dictating my personal
perception of usability regarding that machine. :) the book is moving between a
dock on my desk, various projectors at work, and my sofa at home on a regular basis.

i'll find the time to disable it for a few hours and see whether that changes
something, but not today. stay tuned.

Is there anything interesting
> in the log file?

attaching the xorg.conf, plus logs for enabled and disabled mode. maybe you find
something interesting. as mentioned above, xrandr whether it works or not is not
leaving any per-run entries.

Comment 8 Brian Wallis 2006-08-07 22:36:27 UTC
I'm seeing the exact same problem. After I have suspended/resumed using a 
suspend2 enabled kernel (2.6.16) on a Gentool system xrandr runs but does 
nothing. This was working before I upgraded to X 7.0.

Video H/W is:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [FireGL 
9000] (rev 01)

# xrandr
 SZ:    Pixels          Physical       Refresh
*0   1400 x 1050   ( 613mm x 230mm )  *-15071
 1   2800 x 1050   ( 613mm x 230mm )   3986 -15071
 2   2680 x 1050   ( 613mm x 230mm )   9442
 3   1280 x 1024   ( 613mm x 230mm )   -15080
 4   2048 x 768    ( 613mm x 230mm )   22705
 5   1024 x 768    ( 613mm x 230mm )   -15081
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none

I'll attach an strace from running xrandr -s 1 and I'll also attach my 

X version is as follows:

X Window System Version 7.0.0
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 7.0
Build Operating System:Linux 2.6.16-suspend2-r8 i686
Current Operating System: Linux flatcat 2.6.16-suspend2-r8 #1 SMP Tue Aug 8 
13:53:35 EST 2006 i686
Build Date: 03 August 2006
Comment 9 Brian Wallis 2006-08-07 22:38:34 UTC
Created attachment 6494 [details]
Brian Wallis's xorg.conf file
Comment 10 Brian Wallis 2006-08-07 22:41:36 UTC
Created attachment 6495 [details]
strace from running xrandr -s 1
Comment 11 Teemu Kiviniemi 2006-10-11 12:42:31 UTC
I've seen exactly the same problem. 

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon
9600 M10]

- Xorg 7.0.22 from Debian Etch
- Linux kernel 2.6.17

I don't know what causes it, but I use suspend-to-ram frequently. The problem
happens with both the binary fglrx and the open source radeon drivers.
Restarting the X server fixes the problem.
Comment 12 Marius Gedminas 2006-10-29 05:26:00 UTC
I don't know if you need another "me too", but here it is: Radeon Mobility 7500,
Xorg 7.1.1.  It used to happen with Xorg 7.0 too.  I always notice it after I've
used software suspend a few times; X restart fixes things.  Neither xrandr nor
xvidtune work, yet show no error messages.
Comment 13 Daniel Stodden 2006-10-29 13:24:12 UTC
last week i did the unspeakable and switched to fglrx-8.28.8 drivers. in part
did because i need switch video modes several times a day between internal LVDS
and external CRT displays. so after waiting 3 month for a bugfix, prostitution
is an option, ok? the other part of me does it anyway every now and then, just
reassure myself that power management with ATI still wo't work so i can safely
return to radeon_drv and keep whining like i always do.

this is not interesting.

what's interesting is that fglrx fails in approximately the same fashion. i
switched forth and back for 2 or 3 times, and then it failed silently just like
the xorg driver.

so maybe it's not radeon_drv to blame?
i didn't search bugzilla yet, have similar problems been reported to other
backends as well?
Comment 14 Alex Efros 2006-10-31 09:25:34 UTC
Looks like this bug isn't related to ATI driver. I've just upgraded from Radeon 
9800 Pro to GeForce 7950 GT and so switched from binary ATI's drivers to Xorg's 
driver 'nv'.

This bug is still exists! After working some time and executing xrandr to
switch between 1280x1024@85 and 1024x768@85 many times xrandr just stop working
leaving me is current video mode. Ctrl-Alt-[+/-] stop working too, so I can't
even manually change video mode.

I'm using xrandr-1.0.2, libXrandr-1.1.1, xorg-server-1.1.1 and xorg-x11-7.1.

More details (including some strace output) can be found here: https://
Comment 15 Marius Gedminas 2006-12-27 11:28:42 UTC
Suspend is not at fault either.  I rebooted my laptop today, never suspended,
never used xrandr either, and now that I tried to use it I find that it doesn't
Comment 16 Heiko Baumann 2007-01-03 15:08:37 UTC
i have the same problem on my zaurus c3000 and found out that not suspend/resume
is the problem in my case. just changing system time forward breaks xrandr.this
is also true for my gentoo notebook.

a simple 

date -s 00:00:00

and no more xrandr -o left|right|normal :(

heikob@nb-heikob ~ $ xdpyinfo | head -n 25
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    70101000
X.Org version: 7.1.1
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2800007, revert to PointerRoot
number of extensions:    31
heikob@nb-heikob ~ $             

nb-heikob wallpaper # eix -vl x11-drivers/xf86-video-i810
* x11-drivers/xf86-video-i810
     Available versions:
                (~)     1.6.0
                (~)     1.7.0-r1
                (~)     1.7.2
                (~)     1.7.2-r1
     Installed versions:  Version: 1.7.2-r1
                          Date:    12:13:30 11/19/06
                          USE:     -debug dri
     Best versions/slot:
                (~)     1.7.2-r1
     Homepage:            http://xorg.freedesktop.org/
     Description:         X.Org driver for Intel cards
     License:             xf86-video-i810

nb-heikob wallpaper #                                        

nb-heikob wallpaper # lspci  | grep VGA
0000:00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated
Graphics Controller (rev 03)
nb-heikob wallpaper #     

can anyone confirm this?

Comment 17 Heiko Baumann 2007-01-03 15:23:20 UTC
Created attachment 8287 [details]
strace of xrandr -o left before date change -> rotation working
Comment 18 Heiko Baumann 2007-01-03 15:24:19 UTC
Created attachment 8288 [details]
strace of xrandr -o left after date change -> rotation not working
Comment 19 Will Alexander 2007-01-18 15:02:49 UTC
(In reply to comment #18)
> Created an attachment (id=8288) [edit]
> strace of xrandr -o left after date change -> rotation not working

I am seeing the same problem.  I added some debug statements to libXrandr and
found that the response status is set to 1 which, according to randr.h, is the
error code for RRSetConfigInvalidConfigTime.  The config time I'm seeing is a
weird number, 906892782, and the timestamp variable being passed to libXrandr is

The man pages seem to indicate that the client should be able to refresh its
configtime.  From the Xrandr man page: 
       XRRTimes returns the time last reported by the server along with the
timestamp the last  configuration  changed.   If  the configuration has changed
since the client last updated its view of the server time, requests  to  change
 the  configuration will fail until the client has an up to date timestamp.

Unfortunately, I can't figure out how to get the client to update its timestamp.
 Any ideas? 
Comment 20 Marius Gedminas 2007-01-31 04:17:02 UTC
libxrandr gets the config_time from the response to a X_RRGetScreenInfo request that it does when xrandr calls XRRGetScreenInfo.

I've changed xrandr.c to print config_time before it calls XRRSetScreenConfigAndRate, and then call XRRGetScreenInfo again and show the new value of config_time, to see if it has changed.  It hasn't.

It seems to me that the problem is on the server side.  The randr extension does not accept the config time that it itself returns.  I might be wrong, of course, all my knowledge about X could be written up on the head of a pin.
Comment 21 Marius Gedminas 2007-02-02 13:54:28 UTC
I believe I have found the bug.

The timestamp transferred in the X protocol is a 32-bit number of milliseconds.

The timestamp stored in the server is a structure that contains two fields: months (!) and milliseconds.

When the server passes the config timestamp to the client, it discards the months part and sends only the milliseconds part.

When the server receives the config timestamp from the client, it tries to guess the "months" part by looking at the current time and then maybe adding or subtracting one.  The guess is wrong after the server has been running long enough (several hours).

I have added two ErrorF calls around the 'if' statement that returns RRSetConfigInvalidConfigTimestamp in randr/randr.c and my Xorg.0.log has this:

  randr request got good config time: 0:-2103495671

for the first few successful xrandr calls, and

  randr request failed with RRSetConfigInvalidConfigTime: client passed 1:-2103495671, server has 0:-2103495671

when it fails.  The server has been running for 8 and a half hours.

The obvious fix would be to ignore the months field and only compare the milliseconds.
Comment 22 Marius Gedminas 2007-02-02 13:56:40 UTC
Created attachment 8585 [details] [review]
add debugging prints to the randr extension on the server side
Comment 23 Marius Gedminas 2007-02-02 14:34:06 UTC
Created attachment 8586 [details] [review]
proposed fix

This patch should fix the problem.  I've compiled a patched X server and will be testing it during the next couple of days
Comment 24 Heiko Baumann 2007-02-03 01:27:07 UTC
i've applied this patch to my zaurus xfree and it works!

no problems after changing date (date -s 00:00:00) :)

i'll test this now and report if the problem comes back. but i think your patch fixed it.

Comment 25 Marius Gedminas 2007-02-05 06:08:56 UTC
I've been using the patched X server for two or three days now, and xrandr never stops working.

Could any X maintainers take a look at the patch and maybe commit it?

(There is one tiny flaw in the patch: I forgot to remove the variable declaration of configTime in ProcRRSetScreenConfig.  That variable is no longer used.)
Comment 26 Heiko Baumann 2007-02-05 07:04:21 UTC
on my zaurus the patched xfree is also working without problems now.

Comment 27 Daniel Stodden 2007-02-08 14:52:56 UTC
applied on an ibm thinkpad t41p, ati mobility firegl, patched xserver-xorg-core 1.1.1-0ubuntu12.

works fine, thanks a lot.

Comment 28 Daniel Stone 2007-02-27 01:31:25 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 29 Dale Sedivec 2007-08-12 20:03:57 UTC
Created attachment 11114 [details] [review]
Previous patch updated for Fedora 7's xorg-x11-server-Xorg-

I made this patch apply to F7's X server which they call (I couldn't quickly find this release on the X.org site).  This patch seems to have fixed this problem for me.  Previously, I would suspend, then resume after a day or two, and find I was stuck in whatever my last video mode was.  xrandr -s had no effect at all.  I've now done several suspend/resume cycles and I am still able to use xrandr -s as expected.
Comment 30 Ulrich Gemkow 2007-08-16 04:34:18 UTC
This patch (which solves the problem) is still not in
mainline. Maybe it should be added before the next
big release.

The bug (and the fix) are obvious.


Comment 31 Eric Anholt 2007-09-04 13:37:52 UTC
cherry-picked to 1.4.

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.