On Thu, 08 Apr 2021, Pekka Paalanen wrote:
> On Thu, 08 Apr 2021 16:49:37 +0300
> Jani Nikula wrote:
>
>> Anyway, this is only tangentially related to the library. I just think
>> we need to take DisplayID better into account also in the *users* of the
>> library, as they shouldn't really even
On Thu, 08 Apr 2021, Simon Ser wrote:
> On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
> 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
On Wed, 07 Apr 2021, Hans Verkuil wrote:
> On 07/04/2021 12:31, Jani Nikula wrote:
>> On Wed, 07 Apr 2021, Hans Verkuil wrote:
>>> It is the most complete EDID parser I know based on the various standards.
>>
>> Does it support pure DisplayID in addition to DisplayID blocks embedded
>> to EDID
On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula
wrote:
> On Thu, 08 Apr 2021, Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
> > jani.nik...@linux.intel.com wrote:
> >
> > > Perhaps that should be the takeaway; try to minimize parsed data
>
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
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
On Thu, 08 Apr 2021 16:49:37 +0300
Jani Nikula wrote:
> Anyway, this is only tangentially related to the library. I just think
> we need to take DisplayID better into account also in the *users* of the
> library, as they shouldn't really even look at the EDID if the plain
> DisplayID is there,
On 07/04/2021 12:31, Jani Nikula wrote:
> On Wed, 07 Apr 2021, Hans Verkuil wrote:
>> It is the most complete EDID parser I know based on the various standards.
>
> Does it support pure DisplayID in addition to DisplayID blocks embedded
> to EDID extension blocks? I think we'll be needing that
On Wed, 07 Apr 2021, Hans Verkuil wrote:
> It is the most complete EDID parser I know based on the various standards.
Does it support pure DisplayID in addition to DisplayID blocks embedded
to EDID extension blocks? I think we'll be needing that sometime in the
near future. (We don't yet support
Hi Pekka,
On 07/04/2021 10:44, Pekka Paalanen wrote:
> Hi all,
>
> with display servers proliferating thanks to Wayland, and the Linux
> kernel exposing only a very limited set of information based on EDID
> (rightfully so!), the need to interpret EDID blobs is spreading even
> more. I would
On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote:
> FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
> definitely be interested in using such as library. A C API with no
> dependencies is pretty important from my point-of-view.
>
> I'd prefer if C++ was not used at
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
definitely be interested in using such as library. A C API with no
dependencies is pretty important from my point-of-view.
I'd prefer if C++ was not used at all (and could almost be baited into
doing the work if that were the
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen said:
> Hi all,
>
> with display servers proliferating thanks to Wayland, and the Linux
> kernel exposing only a very limited set of information based on EDID
> (rightfully so!), the need to interpret EDID blobs is spreading even
> more. I would
12 matches
Mail list logo
