Description of problem: Running xorg-x11-drv-i810-1.6.5-19.fc7, I've noticed that 'intel' seems to drive different monitor frequencies than 'i810' for the same monitor/settings/xorg.conf. Running on two different LCD monitors, if my xorg.conf says 'i810', I consistently get Horiz rate of 79.8kHz and Vert rate of 74.6Hz. If I only change i810->intel and restart X, I consistently get Horiz rate of 83.0kHz and Vert rate of 77.8Hz (the last is above supported rate (~75Hz) for both monitors). I've also noticed inconsistencies between the rates reported by my monitors and that reported by xrandr when I run with 'intel': xrandr reports Horiz is 80kHz (vs. monitor reporting 83kHz) and Vert is 75Hz (vs. monitor reporting 77.8Hz). Version-Release number of selected component (if applicable): xorg-x11-drv-i810-1.6.5-19.fc7 How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 152569 [details] Xorg.0.log using 'intel'; running with 77.8Hz Vert (thinks it 75Hz)
Created attachment 152570 [details] Xorg.0.log using 'intel'; after 'xrandr --rate 60' Ran 'xrandr --rate 60' to stabilize montitor.
Created attachment 152571 [details] Xorg.0.log using 'i810'; running at 75Hz (monitor thinks it 75Hz)
Continue to have this problem with latest Rawhide (Test4?)? 'xrandr --rate 60' is now my best friend....;) This is on Thinkpad X60. [Monitor thinks it is receiving 83kHz/78Hz, driver thinks it is sending 80kHz/75Hz). Monitor pops up OSD, goes to sleep, etc.]
Created attachment 153739 [details] Xorg.0.log running w/intel and w/ModeDebug I set 'ModeDebug' to true in xorg.conf. Attached is Xorg.0.log from a run that: 1. restarted server after logging off from a previous session 2. logged in using gdmgreeter screen (this seems to be a lower resolution than with 'i810') 3. screen came up, with H over monitor limit (83.2kHz, max is 80kHz), and V over monitor limit (77.8Hz, max is 75Hz) 4. ran 'xrandr --rate 60' to stabilize monitor (xrandr actually thinks the screen is 59.9Hz) I'm hoping this is useful.....
I tried to run a similar scenario with i810 to compare, but i810 appears not support 'ModeDebug': (WW) I810(0): Option "ModeDebug" is not used
This seems to be working with xorg-x11-drv-i810-2.0.0-5.fc8. Here is output of xrandr: [tbl@localhost ~]$ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280 VGA connected 1280x1024+0+0 (normal left inverted right) 376mm x 301mm 1280x1024 60.0*+ 75.0 59.9 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 640x480 75.0 72.8 60.0 720x400 70.1 LVDS connected 1024x768+0+0 (normal left inverted right) 246mm x 185mm 1024x768 50.0*+ 60.0 40.0 800x600 60.3 640x480 60.0 59.9 TV disconnected (normal left inverted right) [tbl@localhost ~]$ No longer need 'xrandr --rate 60'! Appears to be selecting 'slower' rate (60Hz rather than 75Hz) by default. Only entry in changelog that seemed 'close': * Wed Jun 06 2007 Adam Jackson <ajax> 2.0.0-4 - Update to git master. Many Xv and DVO fixes. Adds support for 945GME, 965GME, G33, Q33, and Q35 chips.
Sorry, but this has reappeared. The only thing I did was to change xorg.conf. I now have to do the 'xrandr --rate 60' thing again. I'll try to recover a backup of the xorg.conf and compare.
Looks like I can make this issue 'go away', by changing the gconf entry desktop->screen->default->0->rate from 75 to 60. With this, gnome logins come up displaying properly at 60Hz. Here is output of 'xrandr': [tbl@localhost ~]$ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280 VGA connected 1280x1024+0+0 (normal left inverted right) 359mm x 287mm 1280x1024 75.0 59.9* 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 LVDS connected (normal left inverted right) 1024x768 50.0 + 60.0 40.0 800x600 60.3 640x480 60.0 59.9 TV disconnected (normal left inverted right) [tbl@localhost ~]$ Flipping this setting back to 75 causes the frequency problem to reappear when using the 'intel' driver. [Works perfectly OK with 'i810' driver.] This is with Thinkpad X60. Here is snippet from 'lspci': 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
Does this still occur in the latest version or the git version? We recently pushed some clock changes that may affect this.
Hmmm.... "xrandr --rate 75" appears to actually get 75! [tbl@localhost ~]$ xrandr --rate 75 [tbl@localhost ~]$ [tbl@localhost ~]$ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280 VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0 + 75.0* 59.9 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 640x480 75.0 72.8 60.0 720x400 70.1 LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x 185mm 1024x768 50.0*+ 60.0 40.0 800x600 60.3 640x480 60.0 59.9 [tbl@localhost ~]$ OSD on monitor says 75!!!!! I'll check later on a (much) older monitor.
(In reply to comment #10) > Does this still occur in the latest version or the git version? We recently > pushed some clock changes that may affect this. Just to note once more -- you shouldn't push reporters to use unpackaged stuff. They should (and could) upgrade to the latest version of their distro, but that's as far as we can go. Aside from the fact, that many people are not able to build upstream packages, some of our stuff (including but not limited to xorg drivers) is pretty heavily patched, so non-reproduction with upstream program doesn't help us that much. We just have to be patient.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Ancient bug, and i810 is no longer present.