linux-kernel - [PATCH 0/5] Improving the situation regarding RGB quantization ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200413214024.46500-1-dev@pp3345.net>
Date:   Mon, 13 Apr 2020 23:40:20 +0200
From:   Yussuf Khalil <dev@...345.net>
To:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc:     Yussuf Khalil <dev@...345.net>
Subject: [PATCH 0/5] Improving the situation regarding RGB quantization ranges

The CTA-861 specification differentiates between IT and CE modes. For the
latter, it requires sources to send "limited RGB quantization range", i.e.,
allowed RGB values are constrained to 16 - 235 (in the 8 bit case). A sink may
indicate support for full range RGB (0 - 255) in CE modes through its EDID,
allowing the source to override the recommendations set by CTA-861.

For computer screens it is usually desirable to have full range RGB output. In
reality, though, many displays set a CE mode as preferred in their EDID and
leave the "Quantization Range Selectable" bit unset despite having no issues
with full range output. Therefore, it makes sense to provide the user with
a method of overriding the standards-compliant selection.

The current situation in DRM regarding the RGB quantization range is somewhat
messy. We have drivers that
 - behave standards-compliant and provide a custom override property (e.g.,
   i915, gma500)
 - behave standards-compliant and provide no override (e.g., vc4)
 - behave standards-compliant and select full range for CE modes if the screen
   indicates support (e.g., tda998x)
 - probably don't care at all

This series is an effort to fix the situation. It introduces a property for
overriding the RGB quantization range that is defined in the DRM core and can
be attached to connectors by all drivers, providing a driver-independent way of
overriding the defaults to userspace. So far, I've wired up the new property in
i915 only.

Yussuf Khalil (5):
  drm/modes: Indicate CEA-861 CE modes to user-space
  drm: Add "RGB quantization range" connector property
  drm: Add drm_connector_state_select_rgb_quantization_range() helper
  drm/atomic-helper: Consider RGB quantization changes to be mode
    changes
  drm/i915: Replace "Broadcast RGB" with "RGB quantization range"
    property

 drivers/gpu/drm/drm_atomic_helper.c           |  6 ++
 drivers/gpu/drm/drm_atomic_uapi.c             |  4 ++
 drivers/gpu/drm/drm_connector.c               | 66 +++++++++++++++++++
 drivers/gpu/drm/drm_modes.c                   | 14 ++++
 drivers/gpu/drm/i915/display/intel_atomic.c   |  8 ---
 .../gpu/drm/i915/display/intel_connector.c    | 39 ++++-------
 .../gpu/drm/i915/display/intel_connector.h    |  2 +-
 .../drm/i915/display/intel_display_types.h    |  8 ---
 drivers/gpu/drm/i915/display/intel_dp.c       | 24 ++-----
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c     | 19 ++----
 drivers/gpu/drm/i915/display/intel_sdvo.c     | 18 ++---
 drivers/gpu/drm/i915/i915_drv.h               |  1 -
 include/drm/drm_connector.h                   | 27 ++++++++
 include/drm/drm_mode_config.h                 |  7 ++
 include/uapi/drm/drm_mode.h                   |  2 +
 16 files changed, 160 insertions(+), 87 deletions(-)

-- 
2.26.0