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

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

[Shengyu Qu]

Usage:
 - X11: xrandr --output <output name> --set "pixel encoding" <encoding>
 - Wayland: proptest -M amdgpu -D <card path> <connector ID> connector
   <pixel encoding ID> <encoding (ID)>
 - Kernel Param: amdgpu.pixel_encoding=<encoding>
   or amdgpu.pixel_encoding=<monitor>:<encoding>,<monitor>:<encoding>

Supported encodings are: "auto" (0) (Default and original behavior), "rgb"
(1), "ycbcr444" (2), "ycbcr422" (4), and "ycbcr420" (8).

This patch series allow users to switch between pixel encodings, which is
specially important when auto gets it wrong (probably because of monitor's
manufacturer mistake) and needs user intervention.

Changes since v1:
 - Some cleanup and rebase
 - Added YUV422 support

Full discussion:
https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_2628536

Original patch by Yassine Imounachen, current version is modified based on
this patch(was rebased by Rafael Carvalho):
https://lists.freedesktop.org/archives/amd-gfx/2024-October/116195.html

Shengyu Qu (2):
  drm/connector: Add "pixel_encoding" to switch between RGB & YUV color
    output modes
  drm/amdgpu: Add "pixel_encoding" DRM connector property support for
    amdgpu

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  36 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h      |   2 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 273 +++++++++++++++++-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
 drivers/gpu/drm/amd/display/dc/core/dc.c      |   8 +
 drivers/gpu/drm/amd/display/dc/dc_stream.h    |   2 +
 drivers/gpu/drm/drm_modes.c                   |  32 ++
 include/drm/drm_connector.h                   |   7 +
 9 files changed, 353 insertions(+), 11 deletions(-)

-- 
2.43.0

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

[Marius Vlad]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

Hi,

Prior work towards this is/was: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/

I have slightly modified version of that, but still working on
getting another driver (besides amd/i915) working with it.

On Tue, Aug 26, 2025 at 02:39:59AM +0800, Shengyu Qu wrote:
> Usage:
>  - X11: xrandr --output <output name> --set "pixel encoding" <encoding>
>  - Wayland: proptest -M amdgpu -D <card path> <connector ID> connector
>    <pixel encoding ID> <encoding (ID)>
>  - Kernel Param: amdgpu.pixel_encoding=<encoding>
>    or amdgpu.pixel_encoding=<monitor>:<encoding>,<monitor>:<encoding>
> 
> Supported encodings are: "auto" (0) (Default and original behavior), "rgb"
> (1), "ycbcr444" (2), "ycbcr422" (4), and "ycbcr420" (8).
> 
> This patch series allow users to switch between pixel encodings, which is
> specially important when auto gets it wrong (probably because of monitor's
> manufacturer mistake) and needs user intervention.
> 
> Changes since v1:
>  - Some cleanup and rebase
>  - Added YUV422 support
> 
> Full discussion:
> https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_2628536
> 
> Original patch by Yassine Imounachen, current version is modified based on
> this patch(was rebased by Rafael Carvalho):
> https://lists.freedesktop.org/archives/amd-gfx/2024-October/116195.html
> 
> Shengyu Qu (2):
>   drm/connector: Add "pixel_encoding" to switch between RGB & YUV color
>     output modes
>   drm/amdgpu: Add "pixel_encoding" DRM connector property support for
>     amdgpu
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  36 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |   3 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h      |   2 +
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 273 +++++++++++++++++-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
>  drivers/gpu/drm/amd/display/dc/core/dc.c      |   8 +
>  drivers/gpu/drm/amd/display/dc/dc_stream.h    |   2 +
>  drivers/gpu/drm/drm_modes.c                   |  32 ++
>  include/drm/drm_connector.h                   |   7 +
>  9 files changed, 353 insertions(+), 11 deletions(-)
> 
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Shengyu Qu]

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

Hi Marius,

Thanks for reply.I have some questions:

1.Can you send patch with only i915/amdgpu first? It's a long-needed 
feature to deal with some monitors/TVs with broken EDID.

2.Is there any method to get the list of supported pixel format by 
current driver? Also maybe we need to take display port's maximum speed 
rate/target refresh rate/resolution into account.

Best regards,
Shengyu

在 2025/8/26 15:24, Marius Vlad 写道:
> Hi,
> 
> Prior work towards this is/was: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/
> 
> I have slightly modified version of that, but still working on
> getting another driver (besides amd/i915) working with it.
> 
> On Tue, Aug 26, 2025 at 02:39:59AM +0800, Shengyu Qu wrote:
>> Usage:
>>   - X11: xrandr --output <output name> --set "pixel encoding" <encoding>
>>   - Wayland: proptest -M amdgpu -D <card path> <connector ID> connector
>>     <pixel encoding ID> <encoding (ID)>
>>   - Kernel Param: amdgpu.pixel_encoding=<encoding>
>>     or amdgpu.pixel_encoding=<monitor>:<encoding>,<monitor>:<encoding>
>>
>> Supported encodings are: "auto" (0) (Default and original behavior), "rgb"
>> (1), "ycbcr444" (2), "ycbcr422" (4), and "ycbcr420" (8).
>>
>> This patch series allow users to switch between pixel encodings, which is
>> specially important when auto gets it wrong (probably because of monitor's
>> manufacturer mistake) and needs user intervention.
>>
>> Changes since v1:
>>   - Some cleanup and rebase
>>   - Added YUV422 support
>>
>> Full discussion:
>> https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_2628536
>>
>> Original patch by Yassine Imounachen, current version is modified based on
>> this patch(was rebased by Rafael Carvalho):
>> https://lists.freedesktop.org/archives/amd-gfx/2024-October/116195.html
>>
>> Shengyu Qu (2):
>>    drm/connector: Add "pixel_encoding" to switch between RGB & YUV color
>>      output modes
>>    drm/amdgpu: Add "pixel_encoding" DRM connector property support for
>>      amdgpu
>>
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  36 +++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |   3 +
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h      |   2 +
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 273 +++++++++++++++++-
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
>>   drivers/gpu/drm/amd/display/dc/core/dc.c      |   8 +
>>   drivers/gpu/drm/amd/display/dc/dc_stream.h    |   2 +
>>   drivers/gpu/drm/drm_modes.c                   |  32 ++
>>   include/drm/drm_connector.h                   |   7 +
>>   9 files changed, 353 insertions(+), 11 deletions(-)
>>
>> -- 
>> 2.43.0
>>


[-- 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 --]

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

[Marius Vlad]

[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]

Hello,
On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
> Hi Marius,
> 
> Thanks for reply.I have some questions:
> 
> 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
> to deal with some monitors/TVs with broken EDID.
I plan on doing that soon, but I don't have a date. I'm in between
holidays atm. Note that I just picked these changes from Andri a few
weeks ago.
> 
> 2.Is there any method to get the list of supported pixel format by current
> driver? Also maybe we need to take display port's maximum speed rate/target
> refresh rate/resolution into account.
Drivers should figure out that what pixel color formats it supports and
use the drm helpers (being added with the patchset) to advertise the
available pixel color formats.  For i915/amdgpu, for the time being, I
plan on just OR'ing the known ones working into a list.

User-space will use this information together with the one it is getting
from EDID to perform a intersection between them. 

"auto" will be the preferred driver choice from those advertised pixel
formats, but most likely (fallback) to RGB as all panels support that.

If EDID is broken it depends on user-space if it presents all the
advertised color formats from the driver. There isn't a way to discern
between panels that do not support YUV formats and panels that do support 
YUV formats but they don't expose that in the EDID.
> 
> Best regards,
> Shengyu
> 
> 在 2025/8/26 15:24, Marius Vlad 写道:
> > Hi,
> > 
> > Prior work towards this is/was: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/
> > 
> > I have slightly modified version of that, but still working on
> > getting another driver (besides amd/i915) working with it.
> > 
> > On Tue, Aug 26, 2025 at 02:39:59AM +0800, Shengyu Qu wrote:
> > > Usage:
> > >   - X11: xrandr --output <output name> --set "pixel encoding" <encoding>
> > >   - Wayland: proptest -M amdgpu -D <card path> <connector ID> connector
> > >     <pixel encoding ID> <encoding (ID)>
> > >   - Kernel Param: amdgpu.pixel_encoding=<encoding>
> > >     or amdgpu.pixel_encoding=<monitor>:<encoding>,<monitor>:<encoding>
> > > 
> > > Supported encodings are: "auto" (0) (Default and original behavior), "rgb"
> > > (1), "ycbcr444" (2), "ycbcr422" (4), and "ycbcr420" (8).
> > > 
> > > This patch series allow users to switch between pixel encodings, which is
> > > specially important when auto gets it wrong (probably because of monitor's
> > > manufacturer mistake) and needs user intervention.
> > > 
> > > Changes since v1:
> > >   - Some cleanup and rebase
> > >   - Added YUV422 support
> > > 
> > > Full discussion:
> > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_2628536
> > > 
> > > Original patch by Yassine Imounachen, current version is modified based on
> > > this patch(was rebased by Rafael Carvalho):
> > > https://lists.freedesktop.org/archives/amd-gfx/2024-October/116195.html
> > > 
> > > Shengyu Qu (2):
> > >    drm/connector: Add "pixel_encoding" to switch between RGB & YUV color
> > >      output modes
> > >    drm/amdgpu: Add "pixel_encoding" DRM connector property support for
> > >      amdgpu
> > > 
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  36 +++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |   3 +
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h      |   2 +
> > >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 273 +++++++++++++++++-
> > >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
> > >   drivers/gpu/drm/amd/display/dc/core/dc.c      |   8 +
> > >   drivers/gpu/drm/amd/display/dc/dc_stream.h    |   2 +
> > >   drivers/gpu/drm/drm_modes.c                   |  32 ++
> > >   include/drm/drm_connector.h                   |   7 +
> > >   9 files changed, 353 insertions(+), 11 deletions(-)
> > > 
> > > -- 
> > > 2.43.0
> > > 
> 






[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Hi,

On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
> Thanks for reply.I have some questions:
> 
> 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
> to deal with some monitors/TVs with broken EDID.

If it's to workaround broken monitors, then it's really not something we
should be doing using a property.

Most likely, those monitors don't support YUV* output and will just need
to be forced to RGB, so it's not something that the user (or the
compositor, really) has to care about.

And it would be broken with every driver, not just i915 and amdgpu.

We already have some quirks infrastructure in place, the only thing we
need to do is create an EDID_QUIRK_NO_$FORMAT, clear
drm_display_info->color_formats based on it, and you're done. No uapi to
agree upon, support, test, and it works with every driver.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Daniel Stone]

Hey,

On Wed, 27 Aug 2025 at 10:41, Maxime Ripard <mripard@kernel.org> wrote:
> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
> > to deal with some monitors/TVs with broken EDID.
>
> If it's to workaround broken monitors, then it's really not something we
> should be doing using a property.
>
> Most likely, those monitors don't support YUV* output and will just need
> to be forced to RGB, so it's not something that the user (or the
> compositor, really) has to care about.
>
> And it would be broken with every driver, not just i915 and amdgpu.
>
> We already have some quirks infrastructure in place, the only thing we
> need to do is create an EDID_QUIRK_NO_$FORMAT, clear
> drm_display_info->color_formats based on it, and you're done. No uapi to
> agree upon, support, test, and it works with every driver.

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.

Cheers,
Daniel

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

[Sebastian Wick]

On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
> Hey,
>
> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard <mripard@kernel.org> wrote:
>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
>> > to deal with some monitors/TVs with broken EDID.
>>
>> If it's to workaround broken monitors, then it's really not something we
>> should be doing using a property.
>>
>> Most likely, those monitors don't support YUV* output and will just need
>> to be forced to RGB, so it's not something that the user (or the
>> compositor, really) has to care about.
>>
>> And it would be broken with every driver, not just i915 and amdgpu.
>>
>> We already have some quirks infrastructure in place, the only thing we
>> need to do is create an EDID_QUIRK_NO_$FORMAT, clear
>> drm_display_info->color_formats based on it, and you're done. No uapi to
>> agree upon, support, test, and it works with every driver.
>
> 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.

Yes!

Broadcast RGB is a property that only works as a workaround for broken
monitors. If user space sets it to a value other than auto, even after
first checking the EDID if the sink supports it, we don't know if the
kernel just changes the values, or also sends the InfoFrame (or the DP
equivalent).

So even if the new property was just for broken sinks, we already have a
similar case, and it makes sense: If the EDID fails to read properly, or
the display has no EDID, the kernel can't really identify the thing, so
you need something in user space anyway.

Even for quirks where you can identify something, user space is a better
fit because we can update things faster. This is one of the goals of
libdisplay-info anyway.

Either way, like Daniel said, this *is* useful for other reasons. We
want to be able to switch between quality and bandwidth.

> Cheers,
> Daniel

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

[Sebastian Wick]

On Wed Aug 27, 2025 at 1:08 PM CEST, Sebastian Wick wrote:
> On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
>> Hey,
>>
>> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard <mripard@kernel.org> wrote:
>>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>>> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
>>> > to deal with some monitors/TVs with broken EDID.
>>>
>>> If it's to workaround broken monitors, then it's really not something we
>>> should be doing using a property.
>>>
>>> Most likely, those monitors don't support YUV* output and will just need
>>> to be forced to RGB, so it's not something that the user (or the
>>> compositor, really) has to care about.
>>>
>>> And it would be broken with every driver, not just i915 and amdgpu.
>>>
>>> We already have some quirks infrastructure in place, the only thing we
>>> need to do is create an EDID_QUIRK_NO_$FORMAT, clear
>>> drm_display_info->color_formats based on it, and you're done. No uapi to
>>> agree upon, support, test, and it works with every driver.
>>
>> 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.
>
> Yes!
>
> Broadcast RGB is a property that only works as a workaround for broken
> monitors. If user space sets it to a value other than auto, even after
> first checking the EDID if the sink supports it, we don't know if the
> kernel just changes the values, or also sends the InfoFrame (or the DP
> equivalent).
>
> So even if the new property was just for broken sinks, we already have a
> similar case, and it makes sense: If the EDID fails to read properly, or
> the display has no EDID, the kernel can't really identify the thing, so
> you need something in user space anyway.
>
> Even for quirks where you can identify something, user space is a better
> fit because we can update things faster. This is one of the goals of
> libdisplay-info anyway.
>
> Either way, like Daniel said, this *is* useful for other reasons. We
> want to be able to switch between quality and bandwidth.

Daniel suggested in the other thread that the last part of the transform
should be done via a connector property. I'll take that at face value
beause I really don't really know what hardware does. What's important
then is however to make it absolutely clear what the transform looks
like exactly to user space, to make it possible to program the CRTC
color pipeline to produce the correct values.

>
>> Cheers,
>> Daniel

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On Wed, Aug 27, 2025 at 11:39:25AM +0100, Daniel Stone wrote:
> Hey,
> 
> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard <mripard@kernel.org> wrote:
> > On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
> > > 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
> > > to deal with some monitors/TVs with broken EDID.
> >
> > If it's to workaround broken monitors, then it's really not something we
> > should be doing using a property.
> >
> > Most likely, those monitors don't support YUV* output and will just need
> > to be forced to RGB, so it's not something that the user (or the
> > compositor, really) has to care about.
> >
> > And it would be broken with every driver, not just i915 and amdgpu.
> >
> > We already have some quirks infrastructure in place, the only thing we
> > need to do is create an EDID_QUIRK_NO_$FORMAT, clear
> > drm_display_info->color_formats based on it, and you're done. No uapi to
> > agree upon, support, test, and it works with every driver.
> 
> 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.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[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

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

On Wed, Aug 27, 2025 at 12:36:53PM +0100, Daniel Stone wrote:
> 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?

Like a great plan :)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

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

[Shengyu Qu]

[-- 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 --]