Hi Marek,
On 09.12.2024 22:46, Marek Vasut wrote:
On 12/9/24 9:46 AM, Nikolaus Voss wrote:
and store the panel's timing in EDID EEPROM.
Oh, that is a new one. Does the EDID EEPROM store the entirety of
'struct display_timing {}' somehow , or is that a custom format ?
Well, sort of ;-). VESA has taken care of this 30 years ago
(https://en.wikipedia.org/wiki/Extended_Display_Identification_Data).
DRM handles this with drm_get_edid() and siblings, e.g. :
EDID can not encode all the information in struct display_timing {} ,
or can it ?
I think what you would be missing are bus_flags , bus_format and
possibly the single/dual link and channel (odd/even) mapping, won't
you ?
Yes, that's right. I use the vendor block for bus_flags and bus_format
now, but that's not standard and not portable of course.
My first idea was to store the DT overlay in the display EEPROM but
a standard 1k EEPROM is too small for that.
Understood. I had the same problem, in the end I went for custom
encoding in the EEPROM but the amount of panels was limited in my
case.
Indeed, DTO does not fit the EEPROM and EDID is not really fitting too
well to DPI/LVDS panels, it has too many fields that are specific to
regular pluggable panels and not useful on DPI/LVDS ones.
The curse of backward-compatibility ;-). Nevertheless, we are doing well
with EDID for years now. 95% is implemented in standard kernel, you just
need a few quirks.
--
Nikolaus Voss
