Message-ID: <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com>
Date:   Thu, 5 Jan 2017 14:46:06 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        "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

Hi Ville,


On 05-01-2017 11:46, Ville Syrjälä wrote:
> 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)?
>

The pixel clock rate is half of the TMDS character rate in 4:2:0
(in 24 bit), but for example in deep color 48 bit it will be the
same rate. There is also a reduction to half of htotal, hactive,
hblank, hfront, hsync and hback but I don't think it's a good
solution to guide us from there. Why does it feel wrong to you
expanding the uapi?

I think its important to say that the chosen colorspace can
improve performance in systems: for example, as I said, 4:2:0
24-bit uses half the rate that RGB 24-bit uses so we have less
trafic in the bus. I am recently working with a FPGA connected
trough pcie and I can definitely say that this is true. But, as
expected, less traffic means less quality in final image so its
not a matter of letting kernel decide, I think its a matter of
user choosing between performance vs. quality.

Best regards,
Jose Miguel Abreu

Powered by blists - more mailing lists