Bug 20594

Summary: 2.6.99.902 breaks native 1680x1050 mode on TMDS -- EDID miss
Product: xorg Reporter: Bernhard Rosenkraenzer <bero>
Component: Driver/intelAssignee: MaLing <ling.ma>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium Keywords: regression
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 20276    
Attachments:
Description Flags
2.6.3 log with ModeDebug
none
2.6.99.902 log with ModeDebug
none
xorg.conf
none
Output of xrandr --verbose on 2.6.3
none
Output of xrandr --verbose on 2.6.99.902 none

Description Bernhard Rosenkraenzer 2009-03-11 01:12:53 UTC
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.
Comment 1 Bernhard Rosenkraenzer 2009-03-11 01:13:23 UTC
Created attachment 23746 [details]
2.6.99.902 log with ModeDebug
Comment 2 Bernhard Rosenkraenzer 2009-03-11 01:13:54 UTC
Created attachment 23747 [details]
xorg.conf
Comment 3 Bernhard Rosenkraenzer 2009-03-11 01:15:21 UTC
Created attachment 23748 [details]
Output of xrandr --verbose on 2.6.3
Comment 4 Bernhard Rosenkraenzer 2009-03-11 01:17:29 UTC
Created attachment 23749 [details]
Output of xrandr --verbose on 2.6.99.902
Comment 5 Bernhard Rosenkraenzer 2009-03-11 01:18:06 UTC
Oops, mistyped -- of course DPMS should be TMDS
Comment 6 Bernhard Rosenkraenzer 2009-03-11 01:22:25 UTC
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
Comment 7 Gordon Jin 2009-03-11 01:28:08 UTC
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?
Comment 8 Bernhard Rosenkraenzer 2009-03-11 01:41:46 UTC
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
Comment 9 MaLing 2009-03-11 03:03:17 UTC
(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
Comment 10 Wang Zhenyu 2009-03-12 08:49:41 UTC
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.