After calling xrandr -s 3 the display turns dark and stays that way even after xrandr -s 0 is called to revert the changes. Even after a restart of the server, the problem persists; I have to reboot the machine to get back to a working X. ==== this appears at restart of xrandr-broken X without rebooting ====== (WW) intel(0): ESR is 0x00000001 (WW) intel(0): Existing errors found in hardware state. ========================================================================
Created attachment 9695 [details] Xorg log, normal first boot
Created attachment 9696 [details] Xorg log after xrandr was called (screen remains dark)
Created attachment 9697 [details] xorg.conf for described case
system info: kernel 2.6.20.7 lspci: pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x29a2 Intel Corporation 82G965 Integrated Graphics Controller git info: last commit (xserver): 38d14e858980a1b0c087344d24bf6aebf755663c last commit (intel driver): b23eae55c8cdd73e0aba1bf7ced283d402ee6470
More trial revealed that the effect does not appear in 100% of the cases with xrandr -s 3 but with xrandr -s 4 it currently does. With earlier checkouts of xserver + video-intel, the use of any xrandr calls was able to cause the effect (e.g. with checkout from 2007-04-04).
== xrandr output w.o. options == Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1024 VGA connected 1280x1024+0+0 (normal left inverted right) 338mm x 270mm 1280x1024 60.0*+ 75.0 59.9 1024x768 75.1 70.1 60.0 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 60.0 59.9 720x400 70.1
the described behaviour is not reproducable here with a host using the i945GM graphics controller; host for which it was reported uses 82G965 Integrated Graphics Controller (rev 02)
You should generally use 'xrandr --output FOO --mode 1024x768' for example, rather than 'xrandr -s', as I understand it. Given that the new options work fine, I'm dropping the priority of this bug and reassigning to Keith, since he'll probably know how to handle legacy randr issues.
we've found a few bugs in the legacy (pre RandR 1.2) selection code in the X server; those may be related to this issue. Note that we do recommend using the newer options as those provide more complete control over the hardware configuration, while the legacy options force the X server to make several guesses about the intended configuration.
Making this an xrandr bug, maybe the old options should just be removed. If not, it might be a server or driver bug...
Any further analysis? This is quite dated.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.