EDID versus VBT, and their cooperation/relationship?!

[Zoran Stojsavljevic]

Hello Coreboot folks,

I am opening the another thread, trying better to understand GFX Coreboot
architecture, as well as Linux GFX one. And relationships between these two.

Here are some rules I'll assume they are correct (my best guess), after I
started investigating this area.

- While BSP/Coreboot (EDID not read from the actual monitor yet), the
only entity which applies for attached monitor for timings is VBT.dat (if
applied in Coreboot, assuming it does).
     - VBT.dat is passed via vBIOS or GOP (dynamically) to Linux kernel
while it boots. How and in which phase it is done, I have very little
understanding. More I do understand if vBIOS (CSM ON) is passed to kernel
(as part of Option ROM), but not really clear to me where vbt.dat (where
exactly ?) will finish after Coreboot is done.
     - No matter what and how vbt.dat is passed and where, monitor's EDID
will be read using DDC/CI protocol, while initializing kernel GFX, to
obtain all the true/natural timing data for the present monitor (if
implemented/applicable).

And here are the questions, regarding what I wrote here:
[1] Where in the kernel structures VBT.dat will be kept/held (it'll be
added on fly after BSP is done, somewhere in the allocated heap - the APIs
describing it will be somewhere here: drivers/gpu/drm/i915/)?
[2] In other words, VBT.dat will be the part of DRM (i915 GFX driver), part
of kernel space, correct?
[3] What about EDID, if it is/was successfully read? It obviously has
precedence over VBT.dat, correct?
[4] Does DRI API (DRILib, DRI -> Direct Rendering Infrastructure) as part
of X11 server, provide the only access to VBT.dat?
[5] Does DRI API (DRILib) as part of X11 server, provide the only access to
EDID, previously read from attached monitor (via DDC/CI protocol)?
[6] Alternative to [4], does DRM API (part of kernel space, top layer,
above i915 driver) provide the only access to VBT.dat?
[7] Alternative to [5], does DRM API provide the only access to EDID?
[8] Please, if you like, add your own understanding of this architecture.
[9] Whatever you have to add, subtract, change... You name it!

I really would like to open this thread in order to clear lot of fog,
created by Linux maintainers, INTEL, and Linux GFX designers, as main
reason driving this email to get much better Linux/kernel GFX
picture/architecture understanding???

Thank you all in advance!
Zoran Stojsavljevic