• Sebastian Wick's avatar
    drm/drm_connector: Document Colorspace property variants · f592e016
    Sebastian Wick authored
    The initial idea of the Colorspace prop was that this maps 1:1 to
    InfoFrames/SDP but KMS does not give user space enough information nor
    control over the output format to figure out which variants can be used
    for a given KMS commit. At the same time, properties like Broadcast RGB
    expect full range quantization range being produced by user space from
    the CRTC and drivers to convert to the range expected by the sink for
    the chosen output format, mode, InfoFrames, etc.
    
    This change documents the reality of the Colorspace property. The
    Default variant unfortunately is very much driver specific and not
    reflected by the EDID. The BT2020 variants are in active use by generic
    compositors which have expectations from the driver about the
    conversions it has to do when selecting certain output formats.
    
    Everything else is also marked as undefined. Coming up with valid
    behavior that makes it usable from user space and consistent with other
    KMS properties for those variants is left as an exercise for whoever
    wants to use them.
    
    v2:
     * Talk about "pixel operation properties" that user space configures
     * Mention that user space is responsible for checking the EDID for sink
       support
     * Make it clear that drivers can choose between RGB and YCbCr on their
       own
    Signed-off-by: default avatarSebastian Wick <sebastian.wick@redhat.com>
    Reviewed-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
    Signed-off-by: default avatarMaxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240702143017.2429975-1-sebastian.wick@redhat.com
    f592e016
drm_connector.h 70.7 KB