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.
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.
Created attachment 4986 [details] [review] Modification of xxxSetSyncRangeFromEdid() in radeon_driver.c and r128_driver.c
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
henry.zhao@sun.com Do you still experience this issue with newer soft ? Please check the status of your issue.
-- 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.