Description of problem: Unless I boot with "nomodeset", the X server will not come up with any resolution better than 800x600 if my external monitor (a 1920x1080 device) is attached. It works at 1024x768 (native laptop monitor resolution) as long as the external monitor is not attached, or if I boot the kernel with "nomodeset". Version-Release number of selected component (if applicable): vanilla Fedora 12 released version. Fedora 11 did not have this problem. How reproducible: This happens whether or not I try including an explict cvt-generated Modeline in my xorg.conf file. Steps to Reproduce: 1. Connect external monitor 2. Start X server 3. Actual results: Server comes up with a max resolution of 800x600 even though both monitors are capable of better. Expected results: Honor my mode line or at least use the largest resolution acceptable to both monitors. Additional info: Laptop: Dell Latitude D520, Intel Core Duo Graphics Chip: Intel 945GM/GMS Xorg driver: intel_drv External monitor: older Dell flat panel (dated January 2006)
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance. This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In order to reproduce the problem again, I have to have the laptop at work. That won't happen again until next Monday or Tuesday. I'll boot without "nomodeset" to reproduce the problem, then attach the logs.
Created attachment 373161 [details] Output from dmesg Here is the output from dmesg
Created attachment 373163 [details] X server configuration file Here is the xorg.conf file
Created attachment 373164 [details] X server log file Here is the Xorg.0.log file
I have attached the requested information
We don't seem to be getting EDID from the external display, at all. Is it connected through a KVM or an especially long VGA cable?
Yes, it does connect through a KVM switch. However, at home where it works fine, it also connects through a similar KVM switch. I do not think you can point the finger there. The problem is, when EDID is not available, then the modes specified in the xorg.conf file (which is generated by system-config-display) should be honored. They are not. I believe that is a bug. It basically means that Xorg cannot work in a reasonable way with any monitors that are too old to implement EDID without the "nomodeset" boot kludge. I understand that the attached xorg.conf file does have other modes in it. However, when I use one that specifies 'Modes "1024x768"' only, it still comes up in low res mode when I connect it to the older monitor at work and boot without "nomodeset". It is obviously defaulting to 800x600 when EDID is not available regardless of what xorg.conf says. For me personally, it's not a big deal, as "nomodeset" does what I need. I only filed the bug report because one of the Red Hat guys on the fedora-list asked me to when I reported that the "nomodeset" workaround worked for me.
intel is a RandR 1.2 driver, you should use RandR 1.2 format for your xorg.conf file, not the old one. See: http://wiki.debian.org/XStrikeForce/HowToRandR12 does it work if you create an appropriate xorg.conf following that format? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can confirm this bug on a Lenovo R61, Fedora 12/x86_64, Intel GM965/GL960 graphics. The external monitor is a Samsung SyncMaster 940T, connected via a standard VGA cable without KVM. When I boot the system, I cannot select a higher resolution than 800x600 unless I remove the external monitor. xrandr --prop does not show an EDID for VGA1. The system was working fine until I made a yum update a few days ago. I guess the bug came with one of the update packages of November 28th, although I do not see a suspicious package: Nov 28 11:57:53 Updated: pulseaudio-libs-0.9.21-1.fc12.x86_64 Nov 28 11:57:54 Updated: libudev-145-14.fc12.x86_64 Nov 28 11:57:55 Updated: pulseaudio-libs-glib2-0.9.21-1.fc12.x86_64 Nov 28 11:57:56 Updated: imsettings-libs-0.107.4-3.fc12.x86_64 Nov 28 11:57:58 Updated: 32:bind-libs-9.6.1-13.P2.fc12.x86_64 Nov 28 11:58:03 Updated: netpbm-10.47.04-2.fc12.x86_64 Nov 28 11:58:09 Updated: udev-145-14.fc12.x86_64 Nov 28 11:58:12 Updated: pulseaudio-0.9.21-1.fc12.x86_64 Nov 28 11:58:13 Updated: pulseaudio-module-bluetooth-0.9.21-1.fc12.x86_64 Nov 28 11:58:15 Updated: libgudev1-145-14.fc12.x86_64 Nov 28 11:58:18 Updated: pulseaudio-utils-0.9.21-1.fc12.x86_64 Nov 28 11:58:20 Updated: schroedinger-1.0.8-3.fc12.x86_64 Nov 28 11:58:21 Updated: jack-audio-connection-kit-0.118.0-1.fc12.x86_64 Nov 28 11:58:23 Updated: pulseaudio-module-gconf-0.9.21-1.fc12.x86_64 Nov 28 11:58:26 Updated: lohit-tamil-fonts-2.4.4-3.fc12.noarch Nov 28 11:58:27 Updated: pulseaudio-module-x11-0.9.21-1.fc12.x86_64 Nov 28 11:58:28 Updated: xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.x86_64 Nov 28 11:58:29 Updated: pulseaudio-gdm-hooks-0.9.21-1.fc12.x86_64 Nov 28 11:58:36 Updated: imsettings-0.107.4-3.fc12.x86_64 Nov 28 11:58:55 Updated: gnome-settings-daemon-2.28.1-8.fc12.x86_64 Nov 28 11:58:58 Updated: gdb-7.0-7.fc12.x86_64 Nov 28 11:58:59 Updated: 32:bind-utils-9.6.1-13.P2.fc12.x86_64 Nov 28 11:58:59 Updated: mailcap-2.1.31-1.fc12.noarch Nov 28 11:59:01 Updated: xorg-x11-drv-evdev-2.3.1-2.fc12.x86_64 Nov 28 11:59:04 Updated: lohit-telugu-fonts-2.4.5-1.fc12.noarch Nov 28 11:59:13 Updated: gnome-user-share-2.28.1-3.fc12.x86_64 Nov 28 11:59:21 Updated: netpbm-progs-10.47.04-2.fc12.x86_64
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.