Re: [PATCH v2 0/2] Add "pixel_encoding" to switch between RGB & YUV color modes

[Shengyu Qu <wiagn233@outlook.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2313 bytes --]

Hi,

Sounds OK to me too.

Cheers,
Shengyu

在 2025/8/27 19:36, Daniel Stone 写道:
> Hey,
> 
> On Wed, 27 Aug 2025 at 12:21, Maxime Ripard <mripard@kernel.org> wrote:
>> On Wed, Aug 27, 2025 at 11:39:25AM +0100, Daniel Stone wrote:
>>> There are other reasons to have uAPI though ...
>>>
>>> One is because you really care about the colour properties, and you'd
>>> rather have better fidelity than anything else, even if it means some
>>> modes are unusable.
>>>
>>> Another is for situations which static quirks can't handle. If you
>>> want to keep headroom on the link (either to free up bandwidth for
>>> other uses), or you accidentally bought a super-long cable so have a
>>> flaky link, you might well want to force it to use lower fidelity so
>>> you can negotiate a lower link rate.
>>>
>>> I'm all for just dtrt automatically, but there are definitely reasons
>>> to expose it to userspace regardless.
>>
>> Oh, yeah, definitely.
>>
>> But bringing the big guns and the requirements we have for those to
>> address the point initially discussed by the gitlab issues seems like
>> biting off more than they can chew.
>>
>> Even more so since whatever uapi we come up with would still depend on
>> the EDIDs, and they would still be broken for these monitors.
> 
> Sounds like we're agreeing with each other then.
> 
> Shengyu's 'I want these broken panels to work' usecase is probably
> best served with an EDID quirk, yeah.
> 
> The reason Marius is working on it is the reasons I said above though
> - some for uses where we'd rather clearly fail out and push an error
> to userspace than continue with visually-degraded output, and some for
> uses where people have bought a too-long cable (or bought a too-short
> one which is now at tension through a 180° bend) so we want to force
> the lowest link rate possible, without dropping to a ridiculously low
> resolution.
> 
> So I don't think these are in tension, and Marius should proceed with
> his work (complete with the proper userspace to back it up), and
> Shengyu should proceed with new in-kernel quirks, which will be
> effective when the properties are set to auto, but hard overridden by
> userspace if it decides otherwise.
> 
> How does that sound?
> 
> Cheers,
> Daniel


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]