From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938329AbdAEKJD (ORCPT ); Thu, 5 Jan 2017 05:09:03 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:50935 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938291AbdAEKHw (ORCPT ); Thu, 5 Jan 2017 05:07:52 -0500 Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , "Jose Abreu" References: <20170104132225.GE31595@intel.com> <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> CC: , Carlos Palminha , , Daniel Vetter From: Jose Abreu Message-ID: <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> Date: Thu, 5 Jan 2017 10:07:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170104163607.GK31595@intel.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.107.19.78] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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]