From: Jose Abreu <Jose.Abreu@synopsys.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Jose Abreu" <Jose.Abreu@synopsys.com>
Cc: <dri-devel@lists.freedesktop.org>,
Carlos Palminha <CARLOS.PALMINHA@synopsys.com>,
<linux-kernel@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
Date: Thu, 5 Jan 2017 10:07:45 +0000 [thread overview]
Message-ID: <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> (raw)
In-Reply-To: <20170104163607.GK31595@intel.com>
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?
Best regards,
Jose Miguel Abreu
>
>> Best regards,
>> Jose Miguel Abreu
>>
>>>
[snip]
next prev parent reply other threads:[~2017-01-05 10:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-30 16:53 [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Jose Abreu
2017-01-04 8:34 ` Daniel Vetter
2017-01-04 10:44 ` Jose Abreu
2017-01-04 13:22 ` Ville Syrjälä
2017-01-04 16:15 ` Jose Abreu
2017-01-04 16:36 ` Ville Syrjälä
2017-01-05 10:07 ` Jose Abreu [this message]
2017-01-05 11:46 ` Ville Syrjälä
2017-01-05 14:46 ` Jose Abreu
2017-01-10 11:16 ` Ville Syrjälä
2017-01-10 12:26 ` Jose Abreu
2017-01-10 15:33 ` Ville Syrjälä
2017-01-10 15:52 ` Ville Syrjälä
2017-01-10 17:01 ` Jose Abreu
2017-01-10 17:21 ` Ville Syrjälä
2017-01-11 10:27 ` Jose Abreu
2017-01-11 11:36 ` Ville Syrjälä
2017-01-16 13:24 ` Jose Abreu
2017-01-16 13:57 ` Ville Syrjälä
2017-01-09 5:22 ` Sharma, Shashank
2017-01-09 11:11 ` Jose Abreu
2017-01-09 12:45 ` Sharma, Shashank
2017-01-09 13:23 ` Jose Abreu
2017-01-09 13:28 ` Sharma, Shashank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com \
--to=jose.abreu@synopsys.com \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).