[v2,0/2] Add Colorspace connector property interface

Message

Shankar, Uma Oct. 31, 2018, 12:05 p.m. UTC

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. Kernel will not give the supported colorspaces since
this is panel dependent and our curremt property infrastructure is
not supporting it. 

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.

Uma Shankar (2):
  drm: Add colorspace property
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c   |  4 ++++
 drivers/gpu/drm/drm_connector.c     | 44 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   |  5 +++++
 include/drm/drm_connector.h         |  7 ++++++
 include/drm/drm_mode_config.h       |  6 +++++
 include/uapi/drm/drm_mode.h         | 24 ++++++++++++++++++++
 7 files changed, 91 insertions(+)

Comments

Sharma, Shashank Nov. 3, 2018, 5:38 a.m. UTC | #1

Hello Uma,

My comments inline.


On 10/31/2018 5:35 PM, Uma Shankar wrote:
> 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. Kernel will not give the supported colorspaces since
> this is panel dependent and our curremt property infrastructure is
> not supporting it.
I am not very sure about this part, consider a situation where, I have 
connected a HDMI 2.0 monitor which supports BT2020 gamut, to a GEN9 
device, running an user-space which can also support BT2020 playback / 
HDR playback. Now, both monitor and user-space supports BT2020 playback, 
but the HW doesn't, and this will create a problem during playback. So I 
gess we need to expose a kernel Cap or property to showcase if the HW 
can support BT2020/DCI-P3 gamut space or not.

- Shashank
> 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.
>
> Uma Shankar (2):
>    drm: Add colorspace property
>    drm/i915: Attach colorspace property and enable modeset
>
>   drivers/gpu/drm/drm_atomic_uapi.c   |  4 ++++
>   drivers/gpu/drm/drm_connector.c     | 44 +++++++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/i915/intel_atomic.c |  1 +
>   drivers/gpu/drm/i915/intel_hdmi.c   |  5 +++++
>   include/drm/drm_connector.h         |  7 ++++++
>   include/drm/drm_mode_config.h       |  6 +++++
>   include/uapi/drm/drm_mode.h         | 24 ++++++++++++++++++++
>   7 files changed, 91 insertions(+)
>