On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Thu, 08 Apr 2021, Simon Ser contact@xxxxxxxxxxx wrote: > > > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula jani.nikula@xxxxxxxxxxxxxxx wrote: > > > > > Perhaps that should be the takeaway; try to minimize parsed data > > > where the consumer needs to know whether it originated from DisplayID or > > > EDID? > > > > So an EDID/DisplayID abstraction layer? > > > > It sounds like only an EDID and DisplayID expert could come up with a > > sane API for that. Also some metadata will only be available in one > > format and not the other. > > Well, some of the data already comes from DisplayID extensions in the > EDID. > > My point is, if you parse displayid and edid into different structures > and APIs, what will the code bases using the library end up looking > like? Not pretty? Implementing the same conditionals all over the place? > Anyway. I feel like I'm derailing this a bit, and I really don't want > that to happen. I think DisplayID is a consideration that should not be > forgotten, but it's probably not the first priority here. I agree with the goal. I'm just saying that it considerably increases the complexity of the task. If you're just doing an EDID library, you can just expose the EDID specific bits with a sane API. If you're designing an abstraction layer, you need to have a good look at both APIs, try to come up with common data structures that fit both, and be aware of the upcoming spec changes to not be stuck with a bad API.
