RandR stops working with MergedFB when the external display is disconnected

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

Could you please provide a strace log using xrandr when it works / doesn't work?

Does xrandr also display such weird refresh rates when it's working? If so, this
might be related to bug 6421.

(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.

So, does it also happen if you disable MergedFB? Is there anything interesting
in the log file?

Created an attachment (id=5577)
Xorg.0.log -- MergedFB off

Created an attachment (id=5578)
Xorg.0.log -- MergedFB off

(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.

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
xorg.conf.

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

Created an attachment (id=6494)
Brian Wallis's xorg.conf file

Created an attachment (id=6495)
strace from running xrandr -s 1

I've seen exactly the same problem.

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

- ASUS M6NE
- 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.

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.

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?

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://
bugs.gentoo.org/show_bug.cgi?id=140079

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
work.

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
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
heikob@nb-heikob ~ $

nb-heikob wallpaper # eix -vl x11-drivers/xf86-video-i810
* x11-drivers/xf86-video-i810
     Available versions:
                        1.4.1.3
                (~) 1.6.0
                        1.6.5
                (~) 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?

regards
the2nd

Created an attachment (id=8287)
strace of xrandr -o left before date change -> rotation working

Created an attachment (id=8288)
strace of xrandr -o left after date change -> rotation not working

(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
0.

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?

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.

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.

Created an attachment (id=8585)
add debugging prints to the randr extension on the server side

Created an attachment (id=8586)
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

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.

regards
the2nd

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.)

on my zaurus the patched xfree is also working without problems now.

regards

applied on an ibm thinkpad t41p, ati mobility firegl, patched xserver-xorg-core 1.1.1-0ubuntu12.

works fine, thanks a lot.

regards,
daniel

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Created an attachment (id=11114)
Previous patch updated for Fedora 7's xorg-x11-server-Xorg-1.3.0.0-9.fc7

I made this patch apply to F7's X server which they call 1.3.0.0 (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.

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.

Thanks!

cherry-picked to 1.4.