Hello to Linux professionals,

Here, some interesting investigation I have to have done, since the thread, from F25 forum, prompted to me many new (unexplored) questions. I do know that chances that somebody to answer to me and put some light on these mysteries are very slim/seldom, nevertheless, I, at least am trying to formulate complex problem, in order to start investigating.

The F25 thread, started this thread, is the following:
Using VAAPI on a headless server
http://www.forums.fedoraforum.org/sh...d.php?t=314571

And, here is the problem definition. Here are some rules I defined, and I'll assume they are correct (my best guess), after I started investigating this area.

- While BSP/BIOS (EDID not read from the actual monitor yet), the only entity which applies for the attached monitor for timings is VBT.dat (if applied in BIOS, 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 BIOS 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 EDID implemented/applicable).

The picture, used for the definition of the below presented questions is the following:



And here are the questions, regarding what I wrote here (and rearding the picture, shown above):
[1] Where in the kernel structures VBT.dat will be kept/held (it'll be added on fly after BSP/BIOS 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 have this thread in order to clear lot of fog, created by Linux maintainers, INTEL, and Linux GFX designers, as main reason to get much better Linux/kernel GFX picture/architecture understanding???

Thank you all in advance!

_nobody_