Mailinglist Archive: radeonhd (265 mails)

< Previous Next >
Re: [radeonhd] KMS EDID gathering
  • From: Alex Deucher <alexdeucher@xxxxxxxxx>
  • Date: Sun, 25 Jan 2009 10:09:46 -0500
  • Message-id: <a728f9f90901250709s16aed028kb27d258db477b21@xxxxxxxxxxxxxx>
On Sun, Jan 25, 2009 at 4:59 AM, Kevin Cody Jr. <kcodyjr@xxxxxxxxx> wrote:

Attached is a patch against airlied's tree which does 3 things to DRM/KMS:


1. Increases DDC read retry from 1 to 10. This seems to have solved, or
actually just masked, my problem with intermittent read failures. I
believe this is a sign of a timing issue.

2. Checks the expected number of extensions before returning the EDID
blob, reissuing the read to obtain the full block if needed.

3. Adds my RV610 to the drm_pciids.h; feel free to ignore this part ;)

I am actively working on a standalone EDID parser in userspace. Now, I
have test data for dealing with extensions. When reasonably complete, I
suggest that my parser be ported into the kernel as a "library" module,
and I will adapt the DRM/KMS code to make use of it. This will allow for
the use of all mode timings, not just those in the first block; as well
as other extended data such as chromaticity and HDMI and other features
that I haven't yet read through the specs for.

However it goes down, I do strongly recommend separating the EDID
parsing from the code which fills the DRM/KMS structs. EDID is
surprisingly flexible when you account for all possible versions,
despite its rigid binary format, and there is no real telling just
exactly where a given datum might be until you're well into the parsing.

I would recommend sending these patches to the dri-devel mailing list
as that is where most drm discussion takes place.

Alex
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx

< Previous Next >
References