Bug 9337 - EDID modes do not participate in validation for CRT monitor
Summary: EDID modes do not participate in validation for CRT monitor
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.2 (2007.02)
Hardware: x86 (IA32) All
: high normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 11749
  Show dependency treegraph
 
Reported: 2006-12-13 19:24 UTC by henry.zhao@oracle.com
Modified: 2007-08-31 08:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Redo modeline pool before mode validation for CRT monitors (884 bytes, patch)
2006-12-13 19:30 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review
xorg-conf-goodlog-badlog.txt (77.93 KB, text/plain)
2007-08-08 09:29 UTC, Alan Swanson
no flags Details

Description henry.zhao@oracle.com 2006-12-13 19:24:06 UTC
In general, radeon driver has its own mode validation process for DFP, LCD
monitors, but it still resorts to xf86ValidateModes() for mode validation for
CRT montiors. In current code, when it calls xf86ValidateModes() for mode 
validation for CRT montiors, it uses default modeline database, without 
taking into consideration of EDID modes even though EDID data may be available.

With the integration of auto-config code into Xorg 7.2, it is possible to
re-organize modeline database for validation to include EDID modes simply
by calling new function xf86SetDDCproperties().
Comment 1 henry.zhao@oracle.com 2006-12-13 19:30:05 UTC
Created attachment 8099 [details] [review]
Redo modeline pool before mode validation for CRT monitors

Call xf86SetDDCproperties() before calling xf86ValidateMode() for mode
validation
for CRT monitors. xf86SetDDCproperties() will create a new modeline pool that
includes modes from EDID data and default modes.
Comment 2 Daniel Stone 2007-02-27 01:35:05 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Alan Swanson 2007-08-08 09:29:35 UTC
After testing xf86-video-ati-6.6.193 I noted, due to the blindingly obvious unadjusted video on ye olde fashioned CRT, that user defined modes are not being sorted preferentially. This was the previous and desired behaviour.

Git bisecting reveals the patch in this bug which was applied just after the patch from bug 10205 that reinforced user mode sorting to be the problem. Reverting fixes the issue though perhaps another solution should be implemented as without it EDID/DDC derived modes are not included in the mode lists.

Note that gitweb is a bit weird for this commit and shows radeon-driver.c being deleted instead of xf86SetDDCproperties being added to it while for radeon_modes.c it's fine?!?
Comment 4 Alan Swanson 2007-08-08 09:29:54 UTC
Created attachment 11045 [details]
xorg-conf-goodlog-badlog.txt

Monitor and modes section of xorg.conf along with good Xorg.log from bisect and bad Xorg.log from 6.6.193 showing mode sorting.
Comment 5 Alex Deucher 2007-08-31 08:01:21 UTC
This should be resolved in ati git master.  Please re-open if you are still having issues.


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.