Dynamically change enumeration list of DRM enumeration property

[Yogish Kulkarni]

Hi,

For letting DRM clients to select output encoding:
Sink can support certain display timings with high output bit-depths using
multiple output encodings, e.g. sink can support a particular timing with
RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want to
select YCbCr422 10-bit over RBG 10-bit output to reduce the link bandwidth
(and in turn reduce power/voltage). If DRM driver automatically selects
output encoding then we are restricting DRM clients from making appropriate
choice.

For selectable output color range:
Certain applications (typically graphics) usually rendered in full range
while some applications (typically video) have limited range content. Since
content can change dynamically, DRM driver does not have enough information
to choose correct quantization. Only DRM client can correctly select which
quantization to set (to preserve artist's intent).

For how to use selectable output encoding with Weston:
I was thinking that DRM should have separate property to list the encodings
supported by sink and Weston will present this list to its client. Your
idea to validate encodings using TEST_ONLY commit and present a list of
timings along with encodings supported by particular timing seems better.
Instead of validating all possible encodings, does it make sense to
validate  only those supported by sink? Irrespective of this we would
anyway need some mechanism which will allow user to select particular
encoding for a particular mode. I was thinking to allow this using new DRM
property "Encoding". Do you have anything better in mind?

(Since I am using my Gmail Id, I feel I should mention that I work at
Nvidia)

Thanks,
-Yogish

On Thu, May 28, 2020 at 6:18 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 28 May 2020 17:38:59 +0530
> Yogish Kulkarni <yogishkulkarni at gmail.com> wrote:
>
> > I am trying to find a way through Weston which will allow setting
> specific
> > encoding at display output.
>
> Hi,
>
> why do *you* want to control that?
>
> Why not let the driver always choose the highest possible encoding
> given the video mode and hardware capability?
>
> I can understand userspace wanting to know what it got, but why should
> userspace be able to control it?
>
> Would people want to pick the encoding first, and then go for the
> highest possible video mode?
>
> > Could you please elaborate on  why it is best
> > to let DRM driver automatically configure which encoding to choose rather
> > than making it selectable by DRM client ? I am not able to find reference
> > to past discussion about this. I was only able to find a proposed change
> -
> > https://lists.freedesktop.org/archives/intel-gfx/2017-April/125451.html
> but
> > am not able to find why it got rejected.
> >
> > Alternatively, is there existing way through which DRM clients can
> specify
> > preference for output encoding ? Or currently it's all up to the DRM
> driver
> > to choose what output encoding to use.
>
> There must be some reason why userspace needs to be able to control it.
> I'm also asking as a Weston maintainer, since I'm interested in how
> this affects e.g. color reproduction or HDR support.
>
> One thing that comes to my mind is using atomic TEST_ONLY commits to
> probe all the possible video modes × encodings for presenting a list to
> the user to choose from, if you have a display configuration GUI. E.g
> with some TV use cases, maybe the user wants to avoid sub-sampling, use
> the native resolution, but limit refresh rate to what's actually
> possible. Or any other combination of the three.
>
>
> Thanks,
> pq
>
> >
> > Thanks,
> > -Yogish
> >
> > On Thu, May 28, 2020 at 1:54 PM Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > > On Thu, May 28, 2020 at 12:29:43PM +0530, Yogish Kulkarni wrote:
> > > > For creating new source property, is it good to follow
> > > > "drm_mode_create_hdmi_colorspace_property()"  as an example ? It
> seems
> > > that
> > > > currently there is no standard DRM property which allows DRM client
> to
> > > set
> > > > a specific output encoding (like YUV420, YUV422 etc). Also, there is
> no
> > > > standard property for letting client select YUV/RGB color range. I
> see
> > > > there are two ways to introduce new properties, 1. do something like
> > > > drm_mode_create_hdmi_colorspace_property 2. create custom property
> > > similar
> > > > to "Broadcast RGB". Is there opinion on which is a preferable way
> to
> > > expose
> > > > encoding and color rage selection property ?
> > >
> > > I guess first question is "why?" Thus far we've gone with the opinion
> that
> > > automatically configuring output stuff as much as possible is best.
> What's
> > > the use-case where the driver can't select this?
> > > -Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200601/cf6f4ca1/attachment.htm>