On Tue, 20 Jun 2023 14:04:14 +0000 "Namit Solanki (QUIC)" <quic_nsola...@quicinc.com> wrote:
> Hi,
>
> I have certain questions for HDR functionality in Weston 12, please help me
>
>
> 1. Drm-backend can read 3D LUT and 1d LUT for each plane?
KMS UAPI does not have per-plane color pipelines yet.
> 2. HDR meta data is read from wayland app and is being sent to display
> driver as connector property?
There is no protocol implementation in Weston yet, meaning that
applications cannot display HDR yet.
Also metadata pass-through from clients to monitor is fundamentally
problematic, and therefore a usable idea only under very special cases.
Passing through metadata for one application surface means that all
other surfaces have probably incorrect or inconsistent color
presentation (mouse cursors, sub-titles, notifications, other
windows...). We cannot know how a monitor processes any specific value
of metadata, meaning that we cannot keep the presentation of any
surface consistent when the metadata sent to the monitor changes.
The monitor may also be driven in a (HDR) mode that does not use
metadata at all, hence pass-through is not possible.
> 3. If planes are capable for tonemapping, tonemapping from planes are
> supported?
KMS does not have an UAPI to off-load color operations to KMS planes
yet.
Weston's DRM-backend does not have the code to inspect and off-load any
color transformations yet, either.
> 4. I think below code is dead code, please correct me if I am
> wrong, please let me know the reason for same (in backend-drm, file
> kms.c function drm_output_apply_state_atomic())
>
> if (!output->deprecated_gamma_is_set) {
>
> ret |= crtc_add_prop_zero_ok(req, crtc,
>
>
> WDRM_CRTC_GAMMA_LUT, 0);
>
> ret |= crtc_add_prop_zero_ok(req, crtc,
>
>
> WDRM_CRTC_DEGAMMA_LUT, 0);
>
> }
It is not dead code. It ensures that there are no left-over DEGAMMA or
GAMMA from previous KMS programs that would mess up Weston's display.
Thanks,
pq
pgpJLGgk3bJW8.pgp
Description: OpenPGP digital signature
