[PATCH v3] Documentation: gpu: Mention the requirements for new properties

[Simon Ser]

On Tuesday, June 15th, 2021 at 09:03, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> indeed it will, but what else could one do to test userspace KMS
> clients in generic CI where all you can have is virtual hardware? Maybe
> in the long run VKMS needs to loop back to a userspace daemon that
> implements all the complex processing and returns the writeback result
> via VKMS again? That daemon would then need a single upstream, like the
> kernel, where it is maintained and correctness verified.

The complex processing must be implemented even without write-back, because
user-space can ask for CRCs of the CRTC.

> Or an LD_PRELOAD that hijacks all KMS ioctls and implements virtual
> stuff in userspace? Didn't someone already have something like that?
> It would need to be lifted to be a required part of kernel UAPI
> submissions, I suppose like IGT is nowadays.

FWIW, I have a mock libdrm [1] for libliftoff. This is nowhere near a full
software implementation with write-back connectors, but allows to expose
virtual planes and check atomic commits in CI.

[1]: https://github.com/emersion/libliftoff/blob/master/test/libdrm_mock.c

> For compositor developers like me knowing the exact formulas would be a huge
> benefit as it would allow me to use KMS to off-load precision-sensitive
> operations (e.g.  professional color management). Otherwise, compositors
> probably need a switch: "high quality color management? Then do not use KMS
> features."

I think for alpha blending there are already rounding issues depending on the
hardware. I wouldn't keep my hopes up for any guarantee that all hw uses the
exact same formulae for color management stuff.