[v11 0/4] Add Colorspace connector property interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.
 - This property is just to inform sink what colorspace
   source is trying to drive.

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
default to an unset state where driver will assign the colorspace
when not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list

v5: Modified the colorspace property creation helper to take
platform specific enum list based on the capabilities of the
platform as suggested by Shashank. With this there is no need
for segregation between DP and HDMI.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the kernel doc as well with more details.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.

v10: Addressed Maarten' review comment, updated the RB from Maarten
and Jani Nikula's ack. Also fixed sparse warnings and checkpatch
complaints.

v11: Addressed Ville's review comments. Modified MACRO names, added
infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace
macro definitions defined in CTA 861.G. Currently linux/hdmi lacks
support for ACE formats, will be added as a separate series.

Uma Shankar (4):
  drm: Add HDMI colorspace property
  drm: Add DP colorspace property
  drm: Add colorspace info to AVI Infoframe
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c      |   4 ++
 drivers/gpu/drm/drm_connector.c        | 104 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_edid.c             |  28 +++++++++
 drivers/gpu/drm/i915/intel_atomic.c    |   1 +
 drivers/gpu/drm/i915/intel_connector.c |   8 +++
 drivers/gpu/drm/i915/intel_drv.h       |   1 +
 drivers/gpu/drm/i915/intel_hdmi.c      |  13 +++++
 include/drm/drm_connector.h            |  50 ++++++++++++++++
 include/drm/drm_edid.h                 |   6 ++
 9 files changed, 215 insertions(+)

-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux