On Dec 19, 2011, at 15:08, Tormod Volden wrote: > On Mon, Dec 19, 2011 at 1:45 AM, Jeremy Huddleston <jerem...@apple.com> wrote: >> <lazy>Can you please link the EDID specification, I just looked on wikipedia >> which is not quite authoritative</lazy> > > Yes, I even edited Wikipedia the last time to correct the year > encoding :) BTW, > http://en.wikipedia.org/wiki/Extended_display_identification_data only > explains 1.3 in detail. I found the 1.3 spec through that wiki page > and the 1.4 verification guide by googling, but I am not sure the > locations are meant/allowed to be public so I will not link to them. > The file names are E-EDID%20Standard.pdf and EEDIDverifGuideRa.pdf > >> >> The changes look logical to me assuming the fields represent the values I >> think they do (based on wikipedia). Still, I'm confused about this > 2006 >> issue. Is that somewhere in the spec? > > Yes, see section 3.2.4 of the latter document (table 3-4). Values > 0-0x0F (1990-2005) are reserved (do not use). > >> What if firmware updates cause the display to support EDID v1.4 but it was >> manufactured in 2005? > > I think the authors of the spec did not think about that possibility > :) But in practice, are there any monitors manufactured before 2006 > that receive firmware updates?
Ok, since it is in the spec, it's on the display manufacturer to deal with that case (presumably by either not updating them or by setting the year to 16, ie 2006). >> To check for <1.4, you should change "edid[0x13] < 4" to "(edid[0x12] == 1 >> && edid[0x13] < 4)" ... your existing check would not work for EDID version >> 2.0. > > Yes, this was sloppy coding. Anyway, to do this properly I think there > is no way around moving the EDID version parsing above the year/week > parsing, and then use the claims_one_point_four that will be defined. > I think it is logic to evaluate the EDID version as soon as possible, > and certainly before any fields which might depend on the version. I > will submit a patch for the rearrangement and hope nobody will > protest, and rebase this patch as a follow-up. Sounds good. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
