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
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?
>
>
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 Displa
t yet support that in the kernel either.)
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
14 module parameter set.
Thanks,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xo
f modes again is the only way for the userspace to distinguish between
the two cases. I don't think there's a shortcut for deciding the current
mode is still valid.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
forcing another mdoeset and retraining the link at lower
> link rate/lane count. This has been proven to pass DP compliance.
> It has been also verified that this avoids the black screens in case of such
> mode failures due to link training failure.
Validation is great, but review is what