Re: HDR functionality in weston 12
On Tue, 20 Jun 2023 14:04:14 +
"Namit Solanki (QUIC)" 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
Re: [RFC 0/9] drm: rcar-du: cmm: Enable 3D LUT support
On Wed, 21 Jun 2023 10:10:22 +0200 Jacopo Mondi wrote: > Hello, this series is based on the RFC sent by Melssa Wen: > "[RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface" > https://lore.kernel.org/dri-devel/20230109143846.1966301-1-m...@igalia.com/ > that introduces CRTC properties to control 3D LUT operations. > > The R-Car DU peripheral has a post-blending color management pipeline (CMM) > composed by (in order of processing) a 3D LUT a 1D LUT and a Color conversion > unit. > > The CMM driver already supported operating the 1D LUT, this series add support > for the cubic LUT (named CLU). > > I've been made aware by Melissa and Pekka that the focus of upstream for > color management properties is now on the definition of the "Plane color > pipeline" properties > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/ > > Unfortunately the model there proposed doesn't match the R-Car DU hardware > which > has color management at the post-blending level and not per plane (I've cc-ed > all the receivers of that series, just in case). Hi, what are the actual use cases for post-blending color pipelines? The pre-blending per-plane color pipelines are important for future Wayland compositors, and post-blending is probably mostly about just encoding for the sink (applying some inverse EOTF), so I've been wondering why the post-blending color hardware seems to be so prevalent and well-developed compared to pre-blending. Is the idea that composition happens in a standard fixed color space, and the post-blending color pipeline converts that to sink-native color space? If so, how do systems get their input content into the composition space first? Or is all this just a side-effect of caring about color on a single plane, and not care at all how other planes with other kinds of content will look? (e.g. TV broadcast vs. sub-titles, program guide, OSD) Thanks, pq > The user-space interface has been validated with dedicated unit tests for > the R-Car DU test suite (kms-test) which are available at: > https://git.sr.ht/~jmondi_/kms-test > > The series validates the usage of the HW interface in the hope of re-starting > discussions and interests in the definition of CRTC color management > properties. > > Thanks >j > > Alex Hung (1): > drm: Add 3D LUT mode and its attributes > > Jacopo Mondi (1): > drm: rcar-du: crtc: Enable 3D LUT > > Kieran Bingham (2): > drm: rcar-du: cmm: Provide 3D-CLU support > drm: rcar-du: kms: Configure the CLU > > Laurent Pinchart (1): > drm: rcar-du: cmm: Refactor LUT configuration > > Melissa Wen (4): > drm/drm_color_mgmt: add shaper LUT to color mgmt properties > drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt > drm/drm_color_mgmt: add function to create 3D LUT modes supported > drm/drm_color_mgmt: add function to attach 3D LUT props > > drivers/gpu/drm/drm_atomic_state_helper.c | 7 ++ > drivers/gpu/drm/drm_atomic_uapi.c | 24 > drivers/gpu/drm/drm_color_mgmt.c | 113 +++ > drivers/gpu/drm/drm_fb_helper.c | 5 + > drivers/gpu/drm/drm_mode_config.c | 21 > drivers/gpu/drm/rcar-du/rcar_cmm.c| 127 -- > drivers/gpu/drm/rcar-du/rcar_cmm.h| 36 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 68 +--- > include/drm/drm_color_mgmt.h | 7 ++ > include/drm/drm_crtc.h| 32 +- > include/drm/drm_mode_config.h | 25 + > include/drm/drm_mode_object.h | 2 +- > include/uapi/drm/drm_mode.h | 17 +++ > 13 files changed, 428 insertions(+), 56 deletions(-) > > -- > 2.40.1 > pgpOUpgZoSYt2.pgp Description: OpenPGP digital signature
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Wed, 2023-06-21 at 09:10 +0200, Javier Martinez Canillas wrote: > !! External Email > > [adding Zack Rusin again who seems to have fallen from the Cc list] > > Albert Esteve writes: > > On 6/10/22 10:59, Daniel Vetter wrote: > > > On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote: > > [...] > > > > > - third issue: These special virtual display properties arent > > > > documented. > > > > Aside from hotspot there's also suggested X/Y and maybe other stuff. > > > > I > > > > have no idea what suggested X/Y does and what userspace should do > > > > with > > > > it. I think we need a new section for virtualized drivers which: > > > > - documents all the properties involved > > > > - documents the new cap for enabling virtual cursor planes > > > > - documents some of the key flows that compositors should implement > > > > for > > > > best experience > > > > - documents how exactly the user experience will degrade if > > > > compositors > > > > pretend it's just a normal kms driver (maybe put that into each of > > > > the > > > > special flows that a compositor ideally supports) > > > > - whatever other comments and gaps I've missed, I'm sure > > > > Simon/Pekka/others will chime in once the patch exists. > > What is missing for these patches to land? If I understood correctly is > just these properties documentation that Sima asked above ? > > > > Great bonus would be an igt which demonstrates these flows. With the > > > interactive debug breakpoints to wait for resizing or whatever this should > > > be all neatly possible. > > > -Daniel > > > > Hi all, > > > > We have been testing the v2 of this patch and it works correctly for us. > > > > First we tested with a patched Mutter, the mouse clicks were correct, > > and behavior was as expected. > > > > But I've also added an IGT test as suggested above: > > https://gitlab.freedesktop.org/aesteve/igt-gpu-tools/-/compare/master...modeset-cursor-hotspot-test?from_project_id=1274 > > > > I could post the IGT patch upstream once Zack's patches land. > > > > Zack, are you planning to re-spin the series soon? Otherwise Albert could > continue working on that if you prefer. Besides mutter I wanted to patch kwin as well, but I haven't been able to find the time to patch it as well. I can respin with discussed changes over the weekend if we're ok with getting this in without kde support from the start. z
