Hello Hans, Pekka,
Thank you for providing your feedbacks on the first level draft of the
library, and for your inputs.
On 3/9/2022 3:09 PM, Pekka Paalanen wrote:
Hi Hans,
thanks! If Shashank agrees, we can see how this would start to look
like. I suppose there would be the occasional patch series sent to this
mailing list and publicly discussed between me and Shashank while we
iterate. You could mostly ignore it if you want until the two of us
need your guidance.
Even if it turns out that this cannot go into edid-decode upstream, I
don't think the exercise is going to go to waste. It would be the
beginnings of a new project.
Based on what I could understand from the discussion so far, I could see
that we have some basic requirements which are suggested by both of you,
like:
- We want to keep the current structure of EDID-decode as unchanged as
possible, and want to keep the C++ states internal.
- We want to make sure that the new library (if any) is C API, and apart
from parsing the EDID, should be independent of EDID-decode core logic.
May I propose something which might be able to keep both the
expectations maintained upto a certain point, and does solve the purpose
as well ? Please consider this and let me know how does it sounds:
- We add a C wrapper library with following set of functions:
- parse_edid_init()
- query_a_particular_info_from_edid()
- destroy_edid()
- At init, Client app calls the library parse_edid_init() function with
EDID (file node or raw data), this is when The library layer allocates a
C struct for this EDID, which has two parts
- base block stuff,
- extension blocks stuff,
- The library calls the internal edid-decode core function just to parse
EDID, and get the edid-state, and then fills this C structure with all
the information from edid-state.
- The library caches the C structure for the EDID, and gives user an
identifier for this EDID.
- At a later stage, when this client tries to extract a particular
infomration from EDID (like does this display support YCBCR420), the
library identifies the EDID from cached EDID, and extracts the
information from cached C struct and responds to the caller API.
- During the display disconnection, client calls and asks the library to
destroy the EDID structures, and it does.
In this way, this library becomes the CPP->C translation layer, and it
takes all the overheads like, and will use the edid-decode core APIs
just for parsing the EDID. The edid-decode state remains internal, used
immediately, and not being exposed to another process.
Will that be something you guys would like to see as a prototype code ?
- Shashank
