On Mon, Jan 24, 2022 at 7:51 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@xxxxxxxx> wrote:
> > But reading code&docs is too hard I guess, safer to assume it's just
> > broken and not supported.
>
> I confirm there's lots of documentation (and even more code ;-),
> which is always great!
> But both are intimidating to me, and most of the documentation covers
> features I'm not interested in, as they're only applicable to fancy
> modern truecolor 3D-capable multi-buffer and multi-head hardware, while
> what I am looking for is usually not documented. E.g. I had a hard
> time to discover how color look-up tables work (gamma_{store,size}!),
> as this is not covered in https://docs.kernel.org/gpu/index.html,
> and none of the tinydrm drivers support CLUT modes.
Hm yeah that part is a bit awkward since due to how Xorg works here
the gamma table is abused to be the lookup table for C8. If we're
adding piles of new Cx formats it might be worth it to structure this
a bit better, e.g. (really just thinking on the spot here):
- have a separate Cx lookup table blob in drm_plane_state (in theory
you could have a different one on each plane and still have an overall
gamma ramp on the crtc)
- change the compat functions which map the legacy gamma ramp to
redirect to the plane gamma ramp if the primary plane is set to Cx
- bonus points for then correctly sizing the lookup table to match the
number of bits in the Cx plane format
But unfiddling this confusion properly is going to be tricky. I think
just continuing the tradition we have for C8 and reusing the crtc
gamma ramp for that is probably fine for now.
And yes that's not documented, because when we fixed the docs for the
entire degamm/CGM/gamma color correction pipeline Cx wasn't the top
priority :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
