Created attachment 488953 [details] xorg.conf+Xorg.0.log with backtrace tail smolt: pub_8d2468c6-375b-4845-9f99-de24ea3a0eaf Version-Release number of selected component (if applicable): kernel-PAE-2.6.38.2-8.fc15.i686 xorg-x11-drv-intel-2.14.0-4.fc15.i686 How reproducible: schizophrenically Steps to Reproduce: 1.build an xorg.conf file 2.or not 3.start X Actual results: 1-X locks up the whole system, or 2-X starts, but using VESA driver @1024x768 3-X starts using intel driver, but at 1024x768 instead of other modes the specs in xorg.conf cover, specifically any included PreferredMode. Expected results: 1-X works at either the PreferredMode, or the highest resolution the specs in xorg.conf cover 2-explicit modelines in xorg.conf are not required to get there 3-xrandr commands are not required to get there Additional info: I've been trying for over 6 hours to get X into 1600x1200, while keeping the framebuffer ttys on 1024x768 (to produce desirable number of rows and columns), on this multiboot Dell GX260 system attached to a p275 IBM Trinitron with bad/missing EDID. All installed operating systems (Mandriva 2010, 2009, 2008.1; Fedora 9; openSUSE 10.0 through 11.4) prior to F15 (updated today) do just fine by supplying a xorg.conf with typical monitor properties like VertRefresh, PreferredMode and DisplaySize. In each of these other systems, explicit specification of modelines has not been required. In the process of trying to come up with a valid xorg.conf to result in 1600x1200 instead of 1024x768, X has locked up the whole machine several times. Attachment is from the last attempt before starting to write here. Along the way, all the while logged in on irc://freenode/#fedora-qa, X was at times refusing to use the intel driver instead of vesa. I also tried using various cmdline options alone or in combination, such as vga=ask, video=1600x1200, vga=0x35a, video=1024x768, vga=0x318 and/or drm.edid_strict=0, or none of them at all. I borrowed & attached a native 1600x1200 LCD with good EDID for about half an hour, and got 1600x1200 with no lockups or other unexpected behavior. >1024x768 is achievable via xrandr commands, but there don't seem to be any discoverable docs on where to put those to be executed on startup in Fedora. In openSUSE there is a comment area in /etc/X11/xinit/xinitrc specifying where to put them, but Fedora's xinitrc looks much too different to guess where they might be safely put, and has no explicit instructions to do so. Through experiment I found a script in /etc/X11/ will work. Nevetheless, specs in xorg.conf should be obeyed. Continued with next attachments...
Created attachment 488954 [details] 352 line tail of /var/log/messages Lots of EDID litter here.
Created attachment 488955 [details] Xorg.0.log from connecting without xorg.conf to 1600x1200 LCD with good EDID Note claim of DPI set to 99,98, but xdpyinfo reports 96x96.
Created attachment 488956 [details] xorg.conf+Xorg.0.g from same machine booted to openSUSE 11.4 (released 20 days ago) & CRT as comment 0 X server 1.9.3. X starts at 1600x1200. Everything relevant to desired monitor characteristics put in xorg.conf is obeyed by X, no xrandr startup scripts or xorg.conf modelines are necessary, and all modes that should be available show up in krandrtray.
Created attachment 490390 [details] from today's update Xorg.0.log with good EDID LCD connected (EE) for AIGLX and GLX. Menu responses generate unexpected delays, e.g. long lag waiting on screen repaint to reflect selection to log out, as well as long lag to actually log out.
*** Bug 693995 has been marked as a duplicate of this bug. ***
As noted upstream in https://bugs.freedesktop.org/show_bug.cgi?id=26345 applying 'Option "DRI" "false"' & 'Option "Shadow" "true"' makes this go away. They should be made compiled-in options for 845 chips.
I don't know whether newer kernel or Xorg may be more forgiving of EDID trouble, but with same hardware as in comment 0, I can't reproduce this in F17.