From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937256AbdAJPdW (ORCPT ); Tue, 10 Jan 2017 10:33:22 -0500 Received: from mga02.intel.com ([134.134.136.20]:28148 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753133AbdAJPdU (ORCPT ); Tue, 10 Jan 2017 10:33:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,344,1477983600"; d="scan'208";a="28579492" Date: Tue, 10 Jan 2017 17:33:15 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jose Abreu Cc: dri-devel@lists.freedesktop.org, Carlos Palminha , linux-kernel@vger.kernel.org, Daniel Vetter Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Message-ID: <20170110153315.GC31595@intel.com> References: <20170104132225.GE31595@intel.com> <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> <20170105114640.GO31595@intel.com> <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com> <20170110111601.GY31595@intel.com> <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 10, 2017 at 12:26:53PM +0000, Jose Abreu wrote: > Hi Ville, > > > On 10-01-2017 11:16, Ville Syrjälä wrote: > > On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote: > >> > > [snip] > > >> 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. > > I was asking if we can look at a specific modeline and whether we > > can tell from that if we would need to output it as 4:2:0. > > Hmm, according to HDMI 2.0 spec there are no 4:2:0 only modes and > the only way to figure out if the mode is 4:2:0 only (or able) is > to parse the VCB and VBD blocks from EDID. The clock is half rate > but this is the source that has to figure it out. The mode is > still passed in a regular way (By VIC, by timing, ...). > > > > >> Why does it feel wrong to you > >> expanding the uapi? > > Because it requires changing every single userspace kms client. And > > it's not something userspace should have to worry about. > > I agree but, as Daniel said [1], we could make these new HDMI 2.0 > features optional and only pass them to userspace if client asked > for them. What do you think? Are you going to update all the userspace clients? Exposing HDMI 2.0 modes only for your favorite client doesn't sound like a good plan to me. If we simply compute from a specific modeline whether it needs to be transmitted as 4:2:0, I suppose we could simply look for a matching mode in the 4:2:0 mode. But that would mean that only the exact modes listed by the EDID will work, and others might not. > > [1] > https://lists.freedesktop.org/archives/dri-devel/2017-January/128683.html > > > > >> 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. > > Image quality control for userspace is a much bigger topic. And > > something we have no real precedent for at the moment (apart from > > user choosing a different fb pixel format). > > > > The performance arument is very hardware dependent, and not really > > all that relevant IMO. If the user wants the big mode they either > > get it or not depending on whether the system can deliver. > > > > Ok. But note that there is no nice way to figure this out. For > example, for a graphics card it all depends (apart from the > graphics HW) on the PCIe bus. If the bus is not free for enough > data rate then user can reach bottlenecks and not output at best > performance. If we gave user the ability to switch from, for > example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated. Userspace won't know anything about such bottlenecks. The kernel can know it and hence should automagically drop into 4:2:0 mode if necessary. > Unless of course we always prefer YCbCr 4:2:0, when possible. I > did this internally for bridge driver dw-hdmi. We always prefer > YCbCr over RGB when they are available. It is user transparent as > the controller does the necessary color space conversion, though, > not ideal in my opinion. My idea was that we'd have a property for the output colorspace and would perhaps default to YCbCr for the CEA modes (as per CEA-861). Though I'm sure some people would cry about that behaviour as well. But for the cases where there is no choice but to use a specific output colorspace, the kernel should just do it automagically IMO. No point in manking life diffcult for userspace. -- Ville Syrjälä Intel OTC