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