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 attachment 5577 [details] Xorg.0.log -- MergedFB off
Created attachment 5578 [details] Xorg.0.log -- MergedFB on
(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 attachment 6494 [details] Brian Wallis's xorg.conf file
Created attachment 6495 [details] 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 attachment 8287 [details] strace of xrandr -o left before date change -> rotation working
Created attachment 8288 [details] 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 attachment 8585 [details] [review] add debugging prints to the randr extension on the server side
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
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 attachment 11114 [details] [review] 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.
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.