The current logic misunderstands the spec about CEA 18byte descriptors. First, the spec doesn't state "detailed timing descriptors" but "18 byte descriptors", so any data record could be stored, mixed timings and other data, just as in the standard EDID. Second, the lower four bit of byte 3 of the CEA record do not contain the number of descriptors, but "the total number of DTDs defining native formats in the whole EDID [...], starting with the first DTD in the DTD list (which starts in the base EDID block)." A device can of course support non-native formats.
As such the number can't be used to determine n, and the existing code will filter non-timing 18byte descriptors anyway.
V2 removes an unused variable warning.
Signed-off-by: Christian Schmidt <schmidt@digadd,de>
On Sun, 2011-11-13 at 09:57 +0100, Christian Schmidt wrote:
The current logic misunderstands the spec about CEA 18byte descriptors. First, the spec doesn't state "detailed timing descriptors" but "18 byte descriptors", so any data record could be stored, mixed timings and other data, just as in the standard EDID.
I don't think the code misinterprets this. But I also don't think your patch changes this interpretation, so that's fine.
Second, the lower four bit of byte 3 of the CEA record do not contain the number of descriptors, but "the total number of DTDs defining native formats in the whole EDID [...], starting with the first DTD in the DTD list (which starts in the base EDID block)." A device can of course support non-native formats.
As such the number can't be used to determine n, and the existing code will filter non-timing 18byte descriptors anyway.
Good catch, thanks.
Reviewed-by: Adam Jackson ajax@redhat.com
- ajax
"CS" == Christian Schmidt schmidt@digadd.de writes:
CS> The current logic misunderstands the spec about CEA 18byte descriptors. CS> First, the spec doesn't state "detailed timing descriptors" but "18 byte CS> descriptors", so any data record could be stored, mixed timings and CS> other data, just as in the standard EDID. CS> Second, the lower four bit of byte 3 of the CEA record do not contain CS> the number of descriptors, but "the total number of DTDs defining native CS> formats in the whole EDID [...], starting with the first DTD in the DTD CS> list (which starts in the base EDID block)." A device can of course CS> support non-native formats.
CS> As such the number can't be used to determine n, and the existing code CS> will filter non-timing 18byte descriptors anyway.
CS> V2 removes an unused variable warning.
CS> Signed-off-by: Christian Schmidt <schmidt@digadd,de>
Tested-by: James Cloos cloos@jhcloos.com
Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv.
-JimC
Christian Schmidt wrote:
Tested with all three applied and they work well on my TV all modes work, which was not the case previously if I added manually the modes listed in xorg log (I have three bogus/not working modes logged by xorg).
I do have a small problem with the interlaced modes - I assumed this was a radeon driver issue (the audio part obviously is - but the top line part is independent of audio)
https://bugs.freedesktop.org/show_bug.cgi?id=35970
I mention it just in case there is some link to the cae spec interlaced timings interpretation/implementation.
dri-devel@lists.freedesktop.org
-
Adam Jackson -
Andy Furniss -
Christian Schmidt -
James Cloos