Bug 6309

Summary:

radeon/r128 fails to read hsync/vsync rates when range descriptor is missing

Product:

xorg

Reporter:

henry.zhao <henry.zhao>

Component:

Driver/Radeon

Assignee:

henry.zhao <henry.zhao>

Status:

RESOLVED MOVED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

low

CC:

alan.coopersmith, alexdeucher, libv, shrek

Version:

git

Keywords:

patch

Hardware:

x86 (IA32)

OS:

Solaris

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Modification of xxxSetSyncRangeFromEdid() in radeon_driver.c and r128_driver.c	none

Description henry.zhao@oracle.com 2006-03-18 11:47:47 UTC

radeon/r128 driver uses its own validation function RADEONValidateDDCModes() 
for mode validation when it detects a DFP/LCD monitor, uses server's 
xf86ValidateMode() for mode validation when it detects a CRT monitor, or 
RADEONValidateDDCModes() failes (mostly due to unavailability of DDC data). In 
either cases, it calls RADEONSetSyncRangeFromEdid() to get monitor hsync/vsync 
numbers if these numbers are not available in a config file.

However, RADEONSetSyncRangeFromEdid() only tries to read Range Limits 
Descriptor from DDC to get hsync/vsync, and if no Range Limits Descriptor exits 
in DDC, it fall backs immediately to default numbers.  This is not right, 
since some monitors do not provide Range Limits Descriptor and if this 
happens, xf86ValidateMode() makes attempts to derive hsyn/vsync numbers from 
other timing sectors.

Comment 1 henry.zhao@oracle.com 2006-03-18 11:55:12 UTC

There are two possible ways to fix the problem:

(1) Since currently RADEONValidateDDCModes() does not use hsync/vsync numbers 
    for validation, and xf86ValidateMode(), which needs hsync/vsync numbers for 
    verification, has its own code in reading hsync/vsync numbers from EDID, 
    the calls to RADEONSetSyncRangeFromEdid() are not needed and therefore can 
    be removed.

(2) In RADEONSetSyncRangeFromEdid(), add the missing part: i.e. when Range 
    Limits Descriptor is not found, derive hsync/vsync numbers from other 
    timing sectors.

However the current version of RADEONValidateDDCModes() collects modes from
EDID block and does not do any valication, which is insufficient. (2) is used
considering future enhancement to this function may need hsync/vsync numbers.

In addition, the way of setting default hsync/vsync numbers (setting low and 
high the same) when no data can be found from EDID is in adeqaute, and should 
be corrected.

Same problem happens to r128 driver and needs to be fixed too.

Comment 2 henry.zhao@oracle.com 2006-03-18 13:02:13 UTC

Created attachment 4986 [details] [review]
Modification of  xxxSetSyncRangeFromEdid() in radeon_driver.c and r128_driver.c

Comment 3 Daniel Stone 2007-02-27 01:31:04 UTC

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Comment 4 chemtech 2013-03-15 14:44:57 UTC

henry.zhao@sun.com
Do you still experience this issue with newer soft ?
Please check the status of your issue.

Comment 5 Martin Peres 2019-11-19 07:28:30 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/1.

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.