Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Daniel Stone <daniel@fooishbar.org>]

Hi,

On Tue, 14 Feb 2023 at 16:57, Harry Wentland <harry.wentland@amd.com> wrote:
> On 2/14/23 10:49, Sebastian Wick wrote:
> From what I've seen recently I am inclined to favor an incremental
> approach more. The reason is that any API, or portion thereof, is
> useless unless it's enabled full stack. When it isn't it becomes
> dead code quickly, or never really works because we overlooked
> one thing. The colorspace debacle shows how even something as
> simple as extra enum values in KMS APIs shouldn't be added unless
> someone in a canonical upstream project actually uses them. I
> would argue that such a canonical upstream project actually has
> to be a production environment and not something like Weston.

Just to chime in as well that it is a real production environment;
it's probably actually shipped the most of any compositor by a long
way. It doesn't have much place on the desktop, but it does live in
planes, trains, automobiles, digital signage, kiosks, STBs/TVs, and
about a billion other places you might not have expected.

Probably the main factor that joins all these together - apart from
not having much desktop-style click-and-drag reconfigurable UI - is
that we need to use the hardware pipeline as efficiently as possible,
because either we don't have the memory bandwidth to burn like
desktops, or we need to minimise it for power/thermal reasons.

Given that, we don't really want to paint ourselves into a corner with
incremental solutions that mean we can't do fully efficient things
later. We're also somewhat undermanned, and we've been using our
effort to try to make sure that the full solution - including full
colour-managed pathways for things like movie and TV post-prod
composition, design, etc - is possible at some point through the full
Wayland ecosystem at some point. The X11 experience was so horribly
botched that it wasn't really possible without a complete professional
setup, and that's something I personally don't want to see. However
...

> I could see us getting to a fully new color pipeline API but
> the only way to do that is with a development model that supports
> it. While upstream needs to be our ultimate goal, a good way
> to bring in new APIs and ensure a full-stack implementation is
> to develop them in a downstream production kernel, alongside
> userspace that makes use of it. Once the implementation is
> proven in the downstream repos it can then go upstream. This
> brings new challenges, though, as things don't get wide
> testing and get out of sync with upstream quickly. The
> alternative is the incremental approach.
>
> We should look at this from a use-case angle, similar to what
> the gamescope guys are doing. Small steps, like:
> 1) Add HDR10 output (PQ, BT.2020) to the display
> 2) Add ability to do sRGB linear blending
> 3) Add ability to do sRGB and PQ linear blending
> 4) Post-blending 3D LUT
> 5) Pre-blending 3D LUT
>
> At each stage the whole stack needs to work together in production.

Personally, I do think at this stage we probably have enough of an
understanding to be able to work with an intermediate solution. We
just need to think hard about what that intermediate solution is -
making sure that we don't end up in the same tangle of impossible
semantics like the old 'broadcast RGB' / colorspace / HDR properties
which were never thought through - so that it is something we can
build on rather than something we have to work around. But it would be
really good to make HDR10/HDR10+ media and HDR games work on HDR
displays, yeah.

Cheers,
Daniel