DRM COLOR_RANGE property

[Russell King - ARM Linux]

Can someone provide a deeper explanation about exactly what this
property represents please?

Does this represent the range of YCbCr values _into_ a YCbCr-to-RGB
conversion (in other words, the range of values in the framebuffer),
or the expected output range from the conversion?

This matters, because a "limited", (iow, eg, BT601 compliant YCbCr)
framebuffer where the Y signal is between 16..235 being displayed
on a full-range RGB output would need different conversion from
needing a limited-range RGB output.

If it is indeed the output, then why is this a property of the plane?
Is that not a property of:

(a) whether the plane is being blended or overlaid onto a graphics
    plane which uses full-range RGB
(b) the properties of the output(s) to which the plane is being
    displayed.

IOW, it seems that the output of the CSC is more to do with what's
downstream of the plane than with the plane itself.

For example, take this situation:

plane 0 - graphics, full range RGB
                                  >-- CRTC --> HDMI sink only supporting
plane 1 - video, limited range YUV              limited range RGB

In order to display the graphics correctly in that scenario, the HDMI
output needs to compress the RGB 0-255 range down to 16..236 to be
compliant.  If the video is limited range, and the CSC produces a
limited range RGB output, then plane 1 gets its range further
compressed at the HDMI output, which surely is undesirable.

It would surely be better, if it's not possible to map the range of
plane 0 to limited range, to instead expand the YUV range and then
recompress it at the HDMI output to match the capabilities of the
attached source.

It also seems logical that describing the range of the RGB plane would
also be sane - if the application is limiting graphics RGB to 16..235,
then you'd want the CSC output to do the same and there'd be no need
for any range expansion or compression.

I'd personally like drm_plane_create_color_properties() to allow
creation of COLOR_ENCODING without COLOR_RANGE (iow, supported_ranges
being zero) until COLOR_RANGE is better defined than it is at present.

Thoughts?

I'm bringing this up, because the hardware I have has a CSC that
accepts BT601 and BT709 formats, controlled by a single bit.  Another
bit controls whether the CSC produces 0..255 output or 16..235 output.
That is then blended/overlaid with the graphics plane (0..255) and
sent to the output.  Having a "limited range" YUV plane produce
16..235 range output makes it look low-contrast compared to the
graphics, which is what would be expected - "16" is not black
compared to the black of the graphics in the same way that "235" is
not white compared to the graphics.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up