Bug 11606

Summary: intel_drv 2.1 setting the mode incorrectly on my SyncMaster 226BW, fuzzy artifacts
Product: xorg Reporter: Eric Dorland <eric>
Component: Driver/intelAssignee: Keith Packard <keithp>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: sndirsch
Version: 7.2 (2007.02)   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log none

Description Eric Dorland 2007-07-14 17:09:28 UTC 
Hello, 

After upgrading to xserver-xorg-video-intel 2.1.0-1 in Debian unstable, my monitor developed 3 strange sections, about 100 pixels tall stretching the entire width of the screen. Anything entering these regions gets sort blurry, making text hard to read. Looking at the information pane on my monitor's OSD displays "62.5kHz 58HZ 1680x1053". Since the monitor only does 1680x1050, this was puzzling.

I decided to do a git bisect between 2.0.0 and 2.1.0, and narrowed the problematic commit down to 1e2e301348b4168aeed38b3fdc6b0e43d5678a86. I haven't the foggiest idea what load detection is, but it seems to be the culprit. While doing the bisection, whenever the weird regions were not present, the OSD reported "62.5kHz 58HZ 1680x1050". I'll attach my xorg.conf in a moment, if there's any other debugging I can do, please let me know.

PS, git bisect is pure gold.
Comment 1 Eric Dorland 2007-07-14 17:10:13 UTC 
Created attachment 10733 [details]
Xorg.0.log
Comment 2 Keith Packard 2007-07-14 20:54:46 UTC 
I committed a pile of fixes yesterday that should make this work in master now; I was trying to be cute with monitor detection and failing miserably. All cuteness banished. Some blinking on i8xx will result.
Comment 3 Eric Dorland 2007-07-14 22:01:59 UTC 
Thanks Keith, I'll give it a whirl tomorrow to see if it helps. And I'm sure any lack of cuteness in the code is offset by your person.
Comment 4 Eric Dorland 2007-07-20 23:03:31 UTC 
*** Bug 11663 has been marked as a duplicate of this bug. ***
Comment 5 Stefan Dirsch 2007-08-03 10:16:25 UTC 
This has been fixed in master branch. Latest changelog entry:

commit 15f71edba37738f8ba279fa07452fda10cc65298
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Sat Jul 28 17:43:29 2007 +0800

    Update Lenovo TV quirk info
Comment 6 Stefan Dirsch 2007-08-03 10:21:18 UTC 
> --- Comment  #2 From Keith Packard 2007-07-14 20:54:46 PST  [reply] ---
> I committed a pile of fixes yesterday that should make this work in master
> now;
If this is correct, one of these two commits fixed it again.

commit ff2be3995d33f9e4b7f63b380f166b6168c9b9c6
Author: Keith Packard <keithp@neko.keithp.com>
Date:   Fri Jul 13 12:47:18 2007 -0700

    Remove hard-coded CRT blanking frobbing for load detection.
    
    CRT blanking needn't be adjusted to perform load detection on 9xx chips,
    and the 8xx load detection path now adjusts blanking just during load
    detection. Adjusting the blanking interval turned out to cause many
    monitors to fail to sync.

commit 00f4587025a3879626623135b0a153fcdb906719
Author: Keith Packard <keithp@neko.keithp.com>
Date:   Fri Jul 13 10:58:06 2007 -0700

    Ensure pipe/output active before doing load detection.
    
    If the pipe or output have been set to DPMSOff, then load detection will
    not work correctly. Also, share the load detection configuration code
    between crt and tv outputs.

I didn't check yet, which one.
Comment 7 Stefan Dirsch 2007-08-06 06:19:28 UTC 
It was none of these two. Instead it was this one:

commit 6f18300aed1340348c6d395f326061b5315be643
Author: Keith Packard <keithp@neko.keithp.com>
Date:   Mon Jul 9 21:29:55 2007 -0700

    Eliminate bogus (and harmful) blanking adjustment for load detect.
    
    Instead of always adding blanking to mode lines, use the FORCE_BORDER
    option on i9xx hardware where it works, and dynamically add a bit of 
    border if necessary on i8xx hardware to make load detection work. This may
    cause flashing when a usable crtc is not otherwise idle when load detection
    is requested.

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.