Isn't the ELD limited to 256 bytes, since verb F2F has an 8-bit offset parameter?
I guess you are right. I saw some checks in the hda code where the ELD size is gt PAGE_SIZE. Confusing really.
I think it'd be a good idea to just dump the entire ELD out to user-space for future flexibility. It's trivial for user-space to ignore the vendor- specific data (since it's always after the standardized data).
Right, if this fits in 512 bytes no reason to drop anything.
Perhaps the vendor-specific data space could be useful for matching audio ports to X displays; there is a 64-bit Port_ID in the ELD that might be used for that, or we could define X/Linux/Unix as the vendor, and specify the format of the vendor-specific data in a way that defines this mapping.
Sounds complicated...The spec says this PortID field is "a ""canned"" field that would be populated through implementation specific mean of default programming before the graphic driver is loaded". Duh? The standard "Monitor Name String" may be easier to use...
That said, the internal APIs our graphics driver uses to write the ELD is currently limited to 96 bytes (the size of the standardized section of the ELD). I'm not sure yet if that's simply because 96 bytes was all that was needed, or if that also ended up being encoded as a HW design limitation.
Looks like the max for ELDv2 is 80 bytes for the baseline+4 for the header.