Created attachment 702649 [details] my Xorg.0.log file relevant to the session Description of problem: All of a sudden on a next boot screen resolution at graphic boot and later on in user desktop session dropped down from normal 1680x1050 to 1024x780 as highest available. Version-Release number of selected component (if applicable): xorg-x11-xinit-1.3.2-7.fc18.x86_64 xorg-x11-drv-synaptics-1.6.3-1.fc18.x86_64 xorg-x11-drv-vmware-12.0.2-3.20120718gite5ac80d8f.fc18.x86_64 xorg-x11-drv-intel-2.21.2-1.fc18.x86_64 xorg-x11-drv-vesa-2.3.2-2.fc18.x86_64 xorg-x11-drv-fbdev-0.4.3-3.fc18.x86_64 xorg-x11-drv-openchrome-0.3.1-1.fc18.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-6.fc18.noarch abrt-addon-xorg-2.1.1-1.fc18.x86_64 xorg-x11-drv-mga-1.6.1-2.fc18.x86_64 xorg-x11-drv-evdev-2.7.3-5.fc18.x86_64 xorg-x11-server-Xorg-1.13.2-4.fc18.x86_64 xorg-x11-resutils-7.5-4.fc18.x86_64 xorg-x11-drv-void-1.4.0-12.fc18.x86_64 xorg-x11-drv-cirrus-1.5.1-3.fc18.x86_64 xorg-x11-drv-wacom-0.16.1-2.fc18.x86_64 xorg-x11-xkb-utils-7.7-5.fc18.x86_64 xorg-x11-font-utils-7.5-10.fc18.x86_64 xorg-x11-server-Xephyr-1.13.2-4.fc18.x86_64 xorg-x11-drv-vmmouse-13.0.0-1.fc18.x86_64 xorg-x11-drv-dummy-0.3.6-2.fc18.x86_64 xorg-x11-drv-nouveau-1.0.6-4.fc18.x86_64 xorg-x11-drv-ast-0.97.0-2.fc18.x86_64 xorg-x11-server-common-1.13.2-4.fc18.x86_64 xorg-x11-server-utils-7.5-16.fc18.x86_64 xorg-x11-xauth-1.0.7-2.fc18.x86_64 xorg-x11-drv-qxl-0.1.0-1.fc18.x86_64 xorg-x11-xfs-1.1.2-2.fc18.x86_64 xorg-x11-utils-7.5-7.fc18.x86_64 xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18.x86_64 (just don't know which one of them is to blame) How reproducible: Don't know, I did nothing in particular and the thing happened on boot the next morning. Steps to Reproduce: 1. 2. 3. Actual results: Detected display resolution remains not higher than (generic) 1024x780, until set manually using xrandr. Expected results: Normal display resolution to be detected on boot, as it used to be before: 1680x1050_60.0 Additional info: $cvt 1680 1050 60 -- gives off the following line # 1680x1050 59.95 Hz (CVT 1.76MA) hsync: 65.29 kHz; pclk: 146.25 MHz Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync but then trying to create a new mode with the command: $xrandr --newmode "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync gives off error: X Error of failed request: BadName (named color or font does not exist) Then, changing name of the new mode works: $xrandr --newmode "1680x1050_OK" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync $xrandr --addmode VGA-1 1680x1050_OK ...And on reboot I have to do it all over again.
**Fresh observations** I've tried a LiveCD and it is the same with the LiveCD -- it automatically detects only 1024x768, but would readily switch to 1680x105 when the above commands used. It used to detect everything normally, both with HDD install and LiveCD. So... it seems something's got wrong either with graphics card or monitor? Also, system time is jumping for no obvious reason.
From the attached Xorg.0.log: 30.928] (==) NOUVEAU(0): Swap limit set to 2 [Max allowed 2] [ 30.959] (II) NOUVEAU(0): Output DVI-I-1 has no monitor section [ 30.973] (II) NOUVEAU(0): Output VGA-1 has no monitor section [ 30.999] (II) NOUVEAU(0): Output TV-1 has no monitor section [ 31.029] (II) NOUVEAU(0): EDID for output DVI-I-1 [ 31.043] (II) NOUVEAU(0): EDID for output VGA-1 [ 31.043] (II) NOUVEAU(0): Printing probed modes for output VGA-1 [ 31.043] (II) NOUVEAU(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) ................................. as compared to one from the machine with no such problem: [ 30.485] (II) NOUVEAU(0): EDID for output DVI-I-1 [ 30.485] (II) NOUVEAU(0): Manufacturer: ACI Model: 22a6 Serial#: 45230 [ 30.485] (II) NOUVEAU(0): Year: 2011 Week: 44 [ 30.485] (II) NOUVEAU(0): EDID Version: 1.3 [ 30.485] (II) NOUVEAU(0): Digital Display Input [ 30.485] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 53 vert.: 30 [ 30.485] (II) NOUVEAU(0): Gamma: 2.20 [ 30.485] (II) NOUVEAU(0): DPMS capabilities: Off [ 30.485] (II) NOUVEAU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 30.485] (II) NOUVEAU(0): First detailed timing is preferred mode [ 30.485] (II) NOUVEAU(0): redX: 0.644 redY: 0.332 greenX: 0.286 greenY: 0.601 [ 30.485] (II) NOUVEAU(0): blueX: 0.152 blueY: 0.076 whiteX: 0.312 whiteY: 0.328 [ 30.485] (II) NOUVEAU(0): Supported established timings: [ 30.485] (II) NOUVEAU(0): 720x400@70Hz [ 30.485] (II) NOUVEAU(0): 640x480@60Hz [ 30.485] (II) NOUVEAU(0): 640x480@67Hz [ 30.485] (II) NOUVEAU(0): 640x480@72Hz [ 30.485] (II) NOUVEAU(0): 640x480@75Hz [ 30.485] (II) NOUVEAU(0): 800x600@56Hz [ 30.485] (II) NOUVEAU(0): 800x600@60Hz [ 30.485] (II) NOUVEAU(0): 800x600@72Hz [ 30.485] (II) NOUVEAU(0): 800x600@75Hz [ 30.485] (II) NOUVEAU(0): 832x624@75Hz [ 30.485] (II) NOUVEAU(0): 1024x768@60Hz [ 30.485] (II) NOUVEAU(0): 1024x768@70Hz [ 30.485] (II) NOUVEAU(0): 1024x768@75Hz [ 30.485] (II) NOUVEAU(0): 1280x1024@75Hz [ 30.485] (II) NOUVEAU(0): Manufacturer's mask: 0 [ 30.485] (II) NOUVEAU(0): Supported standard timings: [ 30.485] (II) NOUVEAU(0): #0: hsize: 1152 vsize 864 refresh: 75 vid: 20337 [ 30.485] (II) NOUVEAU(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 ...................................... Obviously, in the first case EDID gives off no data, while in the second it detects everything. Both Fedora 18 installations x86_64 with the same updates installed. Therefore, given all the above, the problem looks like being caused by hardware: perhaps, broken cable or something of the sort. In fact, right before the problem showed up I swapped the cable many times, so maybe it just got damaged at the bending spot. Will check with a new cable.
Checked with a cable known to be fine, didn't help.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.