Message-ID: <20170105114640.GO31595@intel.com>
Date:   Thu, 5 Jan 2017 13:46:40 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
Cc:     dri-devel@...ts.freedesktop.org,
        Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        linux-kernel@...r.kernel.org,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

On Thu, Jan 05, 2017 at 10:07:45AM +0000, Jose Abreu wrote:
> Hi Ville,
> 
> 
> On 04-01-2017 16:36, Ville Syrjälä wrote:
> > On Wed, Jan 04, 2017 at 04:15:01PM +0000, Jose Abreu wrote:
> >>
>  
> [snip]
> 
> >>> Why does userspace need to know this? My thinking has been that the
> >>> driver would do the right thing automagically.
> >>>
> >>> We do probably want some kind of output colorspace property to allow the
> >>> user to select between RGB vs. YCbCr etc. But I think even with that we
> >>> should still allow the driver to automagically select YCbCr 4:2:0 output
> >>> since that's the only way the mode will work.
> >> I agree. When only 4:2:0 is supported there is no need to expose
> >> the flag to userspace. How shall then I signal drivers for this
> >> 4:2:0'only sampling mode?
> >>
> >> So, for the remaining modes, you propose a new field in the mode
> >> structure called 'colorspace' which contains the list of
> >> supported sampling modes for the given mode? I think it would be
> >> a nice addition. This way if a mode supports only RGB we only
> >> passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0
> >> flag, ... And then user could select. We also have to inform user
> >> which one is being actually used.
> > IIRC there aren't any "RGB only" modes or anything like that. So
> > YCbCr 4:2:0 is the special case here. We could just add something to the
> > mode struct for it, or do we already have some other flags thing that's
> > not exposed to userspace? And I guess drivers should be able to opt into
> > supporting these 4:2:0 modes in similar way they opt into
> > interlaced/stereo/whatever.
> 
> I mean, if a source EDID does not declare support for YCbCr modes
> (4:2:2 and 4:4:4 [i think they have to be both supported if sink
> supports != RGB]) then only RGB can be used. Or is any YCbCr that
> is pre-required? Still, I see your point. When EDID declares
> support for YCbCr then all modes can use it, and not only some of
> them.
> 
> I think for stereo modes the flags can be opt in/out in userspace
> exposing. There is a function called
> drm_mode_expose_to_userspace() which only exposes stereo modes if
> user asks to. We could do something similar for 4:2:0 modes (or
> even for all pixel encoding). i.e. expose which encoding can be
> used in current video mode. What do you think?
> 
> About drivers opting in for 4:2:0 modes, then you propose a new
> field in drm_connector (called for example ycbcr_420_allowed)
> which only does the parsing of the 4:2:0 modes and adds them to
> the list when set to true?

Thinking a bit more about this, we do have a slight problem with not
exposing this information to userspace. Namely we can't actually tell
whether any user provided mode would need to output as 4:2:0 or not.
With the new flag userspace could at least inherit that from the kernel
and pass it back in. But still, expanding the uapi for something like
this feels quite wrong to me. Can we simply look at a particular user
supplied mode and tell whether it needs to be output as 4:2:0 (based
on eg. dotclock)?

-- 
Ville Syrjälä
Intel OTC

Powered by blists - more mailing lists