-
25th June 2017, 05:50 AM
#1
EDID versus VBT.dat structure, and their cooperation/relationship?!
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_
Similar Threads
-
By SwampKracker in forum Linux Chat
Replies: 8
Last Post: 18th July 2009, 05:19 AM
-
By pete_1967 in forum Wibble
Replies: 40
Last Post: 31st October 2007, 10:22 PM
-
By tomcat in forum Linux Chat
Replies: 2
Last Post: 26th August 2007, 06:22 PM
-
By Wayne in forum Linux Chat
Replies: 19
Last Post: 27th March 2007, 02:45 PM
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
[[template footer(Guest)]]