Created attachment 23745 [details] 2.6.3 log with ModeDebug On an Intel 82Q35 (PCI ID 8086:29b2 subsystem 8086:4f4a) connected to an Acer 22" display, xf86-video-intel 2.6.99.902 breaks the display's native 1680x1050 mode on DPMS -- instead, it goes to 1024x768 (and otherwise works well). 2.6.3 works right.
Created attachment 23746 [details] 2.6.99.902 log with ModeDebug
Created attachment 23747 [details] xorg.conf
Created attachment 23748 [details] Output of xrandr --verbose on 2.6.3
Created attachment 23749 [details] Output of xrandr --verbose on 2.6.99.902
Oops, mistyped -- of course DPMS should be TMDS
Trying to add 2.6.3's 1650x1080 mode manually to 2.6.99.902 through xrandr results in [arklinux@localhost ~]$ xrandr --verbose --newmode 1650x1080 146.2 1680 1960 2136 2240 1050 1053 1059 1089 -HSync +VSync [arklinux@localhost ~]$ xrandr --verbose --addmode TMDS-1 1650x1080 [arklinux@localhost ~]$ xrandr --verbose -s 1650x1080 Size 1650x1080 not found in available modes [arklinux@localhost ~]$ xrandr --verbose Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048 VGA disconnected (normal left inverted right x axis y axis) Identifier: 0x3b Timestamp: 2667939 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: TMDS-1 connected 1024x768+0+0 (0x3d) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x3c Timestamp: 2667939 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 Panning: 0x0+0+0 Tracking: 0x0+0+0 Border: 0/0/0/0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 1024x768 (0x3d) 65.0MHz -HSync -VSync *current h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x3e) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 640x480 (0x3f) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz 1650x1080 (0xf6) 146.2MHz -HSync +VSync h: width 1680 start 1960 end 2136 total 2240 skew 0 clock 65.3KHz v: height 1050 start 1053 end 1059 total 1089 clock 59.9Hz
Thanks for the quick try for 2.6.99.902 and filing this bug. So the new driver doesn't detect the monitor EDID. Are you able git-bisect to find the culprit commit on master branch?
2.6.99.902 actually does the right thing if (and only if) - KMS is enabled (on 2.6.29-rc7 with drm from drm-intel-next) - The i915 module is loaded before the X server is started Unfortunately I don't have the time to bisect head right now, will try later
(In reply to comment #8) > 2.6.99.902 actually does the right thing if (and only if) > - KMS is enabled (on 2.6.29-rc7 with drm from drm-intel-next) > - The i915 module is loaded before the X server is started > Unfortunately I don't have the time to bisect head right now, will try later hi, could you try commit id: f1ca56e17d0ecd4f1299061a6b3272bfd289e123. I guess the problem is from commit id:ddedf19f889da2ce6d69a3afce4665e2245682fa. Thanks
Fixed in git master. commit dc3ff0b514b609448025680778f0e95e1980a5d8 Author: Zhenyu Wang <zhenyu.z.wang@intel.com> Date: Thu Mar 12 16:32:02 2009 +0800 Revert "SDVO: Switch control bus only before DDC access" This reverts commit ddedf19f889da2ce6d69a3afce4665e2245682fa. After i2c STOP, control bus will return back to internal registers. So this brings back to origin code that we switch to DDC bus before START. But it's ideal to only issue DDC bus switch after STOP, not before every START, which might eliminate some complains from SDVO device, that will be another patch later.
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.