From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Thu, 19 Jan 2017 18:45:36 +0200 Subject: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data In-Reply-To: References: <1484656294-6140-1-git-send-email-narmstrong@baylibre.com> Message-ID: <41264092.NJkav44OGl@avalon> To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org Hi Hans and Jose, On Thursday 19 Jan 2017 16:30:57 Hans Verkuil wrote: > On 01/19/17 16:21, Jose Abreu wrote: > > On 18-01-2017 20:49, Laurent Pinchart wrote: > >> Ideally the bridge mode set operation should be extended to take format > >> and colorspace information (or another bridge operation should be created > >> for that purpose, I'm still undecided). As that's quite a big change, I'm > >> fine if you start by passing a fixed format and colorspace through > >> platform data. I would however like the format to use the media bus > >> format codes defined in include/uapi/linux/media-bus-format.h. > >> > >> As far as I'm aware we have no colorspace definitions in DRM, so we would > >> need to fix that. V4L2 handles colorspaces, and the API went through > >> several iterations before we got it working, with stupid mistakes that > >> we don't want to repeat here. > >> > >> Jose pointed to > >> https://patchwork.kernel.org/patch/9495153/ as a starting point, and I > >> would like to point out the format and colorspace are two different > >> things. A colorspace is a combination of an encoding and quantization > >> and transfer functions. Hans Verkuil has researched this topic for V4L2 > >> (see https://gstreamer.freedesktop.org/data/events/gstreamer-> >> conference/2015/Hans Verkuil - Colorspaces and HDMI.pdf and > >> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/colorspaces.html), we > >> *really* want to involve him in this discussion. > >> > >> I believe colorspace information should be shared between V4L2 and DRM > >> the same way we share the media bus formats (We should have done so for > >> 4CCs as well but it's unfortunately too late for that). > > > > Hmm, I am always confusing this :/ So, what I was refering as > > "color space" is in reality the encoding (pixel encoding). In > > HDMI the pixel encoding can be RGB 4:4:4, YCbCr 4:4:4, YCbCr > > 4:2:2 and YCbCr 4:2:0. We also have color depth which can be from > > 8-bit to 16-bit. Besides this there is also colorimetry. There's two separate concepts here, the color encoding and the pixel format. The color encoding defines how non-linear R'G'B' is transformed to non-linear Y'CbCr (or whether to stick to R'G'B' of course). It's a mathematical formula, and along with the quantization defines how the numerical Y'CbCr values are obtained. The pixel format then defines the number of bits per sample, as well as the subsampling factors. The media bus codes thus roughly correspond to pixel formats (although they also define whether the color encoding uses RGB or YCbCr, but don't define the color encoding itself or the quantization method). > > I've used media-bus-format.h to successfully pass information > > across a V4L2 driver but I've used it in BGR24 only, which is RGB > > 4:4:4 8 bit, which in media-bust-format.h would correspond to > > MEDIA_BUS_FMT_BGR888_1X24. So, I don't know exactly what is the > > support for other encodings and what if there's support for color > > depth. If there is then great, but if not then support for this > > should also be added. We have a bunch of YUV media bus formats defined in the kernel (see https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/subdev-formats.html#v4l2-mbus-pixelcode). We're missing some that would be needed here (namely YUV 4:4:4 in 12bpp and I believe the 4:2:0 formats), but it's just a matter of adding new definitions with the related documentation. > > DRM already parses successfully the supported encodings from EDID > > and stores them in a structure. Note that this is the output > > encoding, not the input one. We can still have RGB as input and > > then output at YCbCr using CSC. The missing point is the > > selection of encoding (either from userspace or from some sort of > > automatic mechanism by the kernel). We need to select both the input and output formats and encodings, and, yes, I believe that at least the output format and encoding should come from userspace. > The list of supported encodings for video capture depends on the HW > capabilities. So the driver will list the supported formats (ENUMFMT) > and userspace then selects a format (S_FMT) from that list. Please note that this is about HDMI encoders and the DRM/KMS subsystem :-) > Most HDMI receivers can convert the input to various RGB/YCbCr formats. > > Deep color support for HDMI has not been added (surprisingly nobody needed > it apparently), but it is pretty easy: new V4L2_PIX_FMT defines should be > added for those. New media bus formats in this case. > When talking about RGB/YCbCr I prefer the term 'color encoding', since > this has nothing to do with colorspaces (sRGB. AdobeRGB, BT.2020, etc.) -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data Date: Thu, 19 Jan 2017 18:45:36 +0200 Message-ID: <41264092.NJkav44OGl@avalon> References: <1484656294-6140-1-git-send-email-narmstrong@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by gabe.freedesktop.org (Postfix) with ESMTPS id BBB466E148 for ; Thu, 19 Jan 2017 16:45:16 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Hans Verkuil Cc: Jose Abreu , laurent.pinchart+renesas@ideasonboard.com, Neil Armstrong , kieran.bingham@ideasonboard.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Hans Verkuil , linux-amlogic@lists.infradead.org List-Id: dri-devel@lists.freedesktop.org SGkgSGFucyBhbmQgSm9zZSwKCk9uIFRodXJzZGF5IDE5IEphbiAyMDE3IDE2OjMwOjU3IEhhbnMg VmVya3VpbCB3cm90ZToKPiBPbiAwMS8xOS8xNyAxNjoyMSwgSm9zZSBBYnJldSB3cm90ZToKPiA+ IE9uIDE4LTAxLTIwMTcgMjA6NDksIExhdXJlbnQgUGluY2hhcnQgd3JvdGU6Cj4gPj4gSWRlYWxs eSB0aGUgYnJpZGdlIG1vZGUgc2V0IG9wZXJhdGlvbiBzaG91bGQgYmUgZXh0ZW5kZWQgdG8gdGFr ZSBmb3JtYXQKPiA+PiBhbmQgY29sb3JzcGFjZSBpbmZvcm1hdGlvbiAob3IgYW5vdGhlciBicmlk Z2Ugb3BlcmF0aW9uIHNob3VsZCBiZSBjcmVhdGVkCj4gPj4gZm9yIHRoYXQgcHVycG9zZSwgSSdt IHN0aWxsIHVuZGVjaWRlZCkuIEFzIHRoYXQncyBxdWl0ZSBhIGJpZyBjaGFuZ2UsIEknbQo+ID4+ IGZpbmUgaWYgeW91IHN0YXJ0IGJ5IHBhc3NpbmcgYSBmaXhlZCBmb3JtYXQgYW5kIGNvbG9yc3Bh Y2UgdGhyb3VnaAo+ID4+IHBsYXRmb3JtIGRhdGEuIEkgd291bGQgaG93ZXZlciBsaWtlIHRoZSBm b3JtYXQgdG8gdXNlIHRoZSBtZWRpYSBidXMKPiA+PiBmb3JtYXQgY29kZXMgZGVmaW5lZCBpbiBp bmNsdWRlL3VhcGkvbGludXgvbWVkaWEtYnVzLWZvcm1hdC5oLgo+ID4+IAo+ID4+IEFzIGZhciBh cyBJJ20gYXdhcmUgd2UgaGF2ZSBubyBjb2xvcnNwYWNlIGRlZmluaXRpb25zIGluIERSTSwgc28g d2Ugd291bGQKPiA+PiBuZWVkIHRvIGZpeCB0aGF0LiBWNEwyIGhhbmRsZXMgY29sb3JzcGFjZXMs IGFuZCB0aGUgQVBJIHdlbnQgdGhyb3VnaAo+ID4+IHNldmVyYWwgaXRlcmF0aW9ucyBiZWZvcmUg d2UgZ290IGl0IHdvcmtpbmcsIHdpdGggc3R1cGlkIG1pc3Rha2VzIHRoYXQKPiA+PiB3ZSBkb24n dCB3YW50IHRvIHJlcGVhdCBoZXJlLgo+ID4+IAo+ID4+IEpvc2UgcG9pbnRlZCB0bwo+ID4+IGh0 dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcGF0Y2gvOTQ5NTE1My8gYXMgYSBzdGFydGluZyBw b2ludCwgYW5kIEkKPiA+PiB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCB0aGUgZm9ybWF0IGFuZCBj b2xvcnNwYWNlIGFyZSB0d28gZGlmZmVyZW50Cj4gPj4gdGhpbmdzLiBBIGNvbG9yc3BhY2UgaXMg YSBjb21iaW5hdGlvbiBvZiBhbiBlbmNvZGluZyBhbmQgcXVhbnRpemF0aW9uCj4gPj4gYW5kIHRy YW5zZmVyIGZ1bmN0aW9ucy4gSGFucyBWZXJrdWlsIGhhcyByZXNlYXJjaGVkIHRoaXMgdG9waWMg Zm9yIFY0TDIKPiA+PiAoc2VlIGh0dHBzOi8vZ3N0cmVhbWVyLmZyZWVkZXNrdG9wLm9yZy9kYXRh L2V2ZW50cy9nc3RyZWFtZXItPiA+PiBjb25mZXJlbmNlLzIwMTUvSGFucyBWZXJrdWlsIC0gQ29s b3JzcGFjZXMgYW5kIEhETUkucGRmIGFuZAo+ID4+IGh0dHBzOi8vbGludXh0di5vcmcvZG93bmxv YWRzL3Y0bC1kdmItYXBpcy91YXBpL3Y0bC9jb2xvcnNwYWNlcy5odG1sKSwgd2UKPiA+PiAqcmVh bGx5KiB3YW50IHRvIGludm9sdmUgaGltIGluIHRoaXMgZGlzY3Vzc2lvbi4KPiA+PiAKPiA+PiBJ IGJlbGlldmUgY29sb3JzcGFjZSBpbmZvcm1hdGlvbiBzaG91bGQgYmUgc2hhcmVkIGJldHdlZW4g VjRMMiBhbmQgRFJNCj4gPj4gdGhlIHNhbWUgd2F5IHdlIHNoYXJlIHRoZSBtZWRpYSBidXMgZm9y bWF0cyAoV2Ugc2hvdWxkIGhhdmUgZG9uZSBzbyBmb3IKPiA+PiA0Q0NzIGFzIHdlbGwgYnV0IGl0 J3MgdW5mb3J0dW5hdGVseSB0b28gbGF0ZSBmb3IgdGhhdCkuCj4gPiAKPiA+IEhtbSwgSSBhbSBh bHdheXMgY29uZnVzaW5nIHRoaXMgOi8gU28sIHdoYXQgSSB3YXMgcmVmZXJpbmcgYXMKPiA+ICJj b2xvciBzcGFjZSIgaXMgaW4gcmVhbGl0eSB0aGUgZW5jb2RpbmcgKHBpeGVsIGVuY29kaW5nKS4g SW4KPiA+IEhETUkgdGhlIHBpeGVsIGVuY29kaW5nIGNhbiBiZSBSR0IgNDo0OjQsIFlDYkNyIDQ6 NDo0LCBZQ2JDcgo+ID4gNDoyOjIgYW5kIFlDYkNyIDQ6MjowLiBXZSBhbHNvIGhhdmUgY29sb3Ig ZGVwdGggd2hpY2ggY2FuIGJlIGZyb20KPiA+IDgtYml0IHRvIDE2LWJpdC4gQmVzaWRlcyB0aGlz IHRoZXJlIGlzIGFsc28gY29sb3JpbWV0cnkuCgpUaGVyZSdzIHR3byBzZXBhcmF0ZSBjb25jZXB0 cyBoZXJlLCB0aGUgY29sb3IgZW5jb2RpbmcgYW5kIHRoZSBwaXhlbCBmb3JtYXQuIApUaGUgY29s b3IgZW5jb2RpbmcgZGVmaW5lcyBob3cgbm9uLWxpbmVhciBSJ0cnQicgaXMgdHJhbnNmb3JtZWQg dG8gbm9uLWxpbmVhciAKWSdDYkNyIChvciB3aGV0aGVyIHRvIHN0aWNrIHRvIFInRydCJyBvZiBj b3Vyc2UpLiBJdCdzIGEgbWF0aGVtYXRpY2FsIGZvcm11bGEsIAphbmQgYWxvbmcgd2l0aCB0aGUg cXVhbnRpemF0aW9uIGRlZmluZXMgaG93IHRoZSBudW1lcmljYWwgWSdDYkNyIHZhbHVlcyBhcmUg Cm9idGFpbmVkLiBUaGUgcGl4ZWwgZm9ybWF0IHRoZW4gZGVmaW5lcyB0aGUgbnVtYmVyIG9mIGJp dHMgcGVyIHNhbXBsZSwgYXMgd2VsbCAKYXMgdGhlIHN1YnNhbXBsaW5nIGZhY3RvcnMuCgpUaGUg bWVkaWEgYnVzIGNvZGVzIHRodXMgcm91Z2hseSBjb3JyZXNwb25kIHRvIHBpeGVsIGZvcm1hdHMg KGFsdGhvdWdoIHRoZXkgCmFsc28gZGVmaW5lIHdoZXRoZXIgdGhlIGNvbG9yIGVuY29kaW5nIHVz ZXMgUkdCIG9yIFlDYkNyLCBidXQgZG9uJ3QgZGVmaW5lIHRoZSAKY29sb3IgZW5jb2RpbmcgaXRz ZWxmIG9yIHRoZSBxdWFudGl6YXRpb24gbWV0aG9kKS4KCj4gPiBJJ3ZlIHVzZWQgbWVkaWEtYnVz LWZvcm1hdC5oIHRvIHN1Y2Nlc3NmdWxseSBwYXNzIGluZm9ybWF0aW9uCj4gPiBhY3Jvc3MgYSBW NEwyIGRyaXZlciBidXQgSSd2ZSB1c2VkIGl0IGluIEJHUjI0IG9ubHksIHdoaWNoIGlzIFJHQgo+ ID4gNDo0OjQgOCBiaXQsIHdoaWNoIGluIG1lZGlhLWJ1c3QtZm9ybWF0Lmggd291bGQgY29ycmVz cG9uZCB0bwo+ID4gTUVESUFfQlVTX0ZNVF9CR1I4ODhfMVgyNC4gU28sIEkgZG9uJ3Qga25vdyBl eGFjdGx5IHdoYXQgaXMgdGhlCj4gPiBzdXBwb3J0IGZvciBvdGhlciBlbmNvZGluZ3MgYW5kIHdo YXQgaWYgdGhlcmUncyBzdXBwb3J0IGZvciBjb2xvcgo+ID4gZGVwdGguIElmIHRoZXJlIGlzIHRo ZW4gZ3JlYXQsIGJ1dCBpZiBub3QgdGhlbiBzdXBwb3J0IGZvciB0aGlzCj4gPiBzaG91bGQgYWxz byBiZSBhZGRlZC4KCldlIGhhdmUgYSBidW5jaCBvZiBZVVYgbWVkaWEgYnVzIGZvcm1hdHMgZGVm aW5lZCBpbiB0aGUga2VybmVsIChzZWUgCmh0dHBzOi8vbGludXh0di5vcmcvZG93bmxvYWRzL3Y0 bC1kdmItYXBpcy91YXBpL3Y0bC9zdWJkZXYtZm9ybWF0cy5odG1sI3Y0bDItbWJ1cy1waXhlbGNv ZGUpLiBXZSdyZSBtaXNzaW5nIHNvbWUgdGhhdCB3b3VsZCBiZSBuZWVkZWQgaGVyZSAobmFtZWx5 IFlVViAKNDo0OjQgaW4gMTJicHAgYW5kIEkgYmVsaWV2ZSB0aGUgNDoyOjAgZm9ybWF0cyksIGJ1 dCBpdCdzIGp1c3QgYSBtYXR0ZXIgb2YgCmFkZGluZyBuZXcgZGVmaW5pdGlvbnMgd2l0aCB0aGUg cmVsYXRlZCBkb2N1bWVudGF0aW9uLgoKPiA+IERSTSBhbHJlYWR5IHBhcnNlcyBzdWNjZXNzZnVs bHkgdGhlIHN1cHBvcnRlZCBlbmNvZGluZ3MgZnJvbSBFRElECj4gPiBhbmQgc3RvcmVzIHRoZW0g aW4gYSBzdHJ1Y3R1cmUuIE5vdGUgdGhhdCB0aGlzIGlzIHRoZSBvdXRwdXQKPiA+IGVuY29kaW5n LCBub3QgdGhlIGlucHV0IG9uZS4gV2UgY2FuIHN0aWxsIGhhdmUgUkdCIGFzIGlucHV0IGFuZAo+ ID4gdGhlbiBvdXRwdXQgYXQgWUNiQ3IgdXNpbmcgQ1NDLiBUaGUgbWlzc2luZyBwb2ludCBpcyB0 aGUKPiA+IHNlbGVjdGlvbiBvZiBlbmNvZGluZyAoZWl0aGVyIGZyb20gdXNlcnNwYWNlIG9yIGZy b20gc29tZSBzb3J0IG9mCj4gPiBhdXRvbWF0aWMgbWVjaGFuaXNtIGJ5IHRoZSBrZXJuZWwpLgoK V2UgbmVlZCB0byBzZWxlY3QgYm90aCB0aGUgaW5wdXQgYW5kIG91dHB1dCBmb3JtYXRzIGFuZCBl bmNvZGluZ3MsIGFuZCwgeWVzLCBJIApiZWxpZXZlIHRoYXQgYXQgbGVhc3QgdGhlIG91dHB1dCBm b3JtYXQgYW5kIGVuY29kaW5nIHNob3VsZCBjb21lIGZyb20gCnVzZXJzcGFjZS4KCj4gVGhlIGxp c3Qgb2Ygc3VwcG9ydGVkIGVuY29kaW5ncyBmb3IgdmlkZW8gY2FwdHVyZSBkZXBlbmRzIG9uIHRo ZSBIVwo+IGNhcGFiaWxpdGllcy4gU28gdGhlIGRyaXZlciB3aWxsIGxpc3QgdGhlIHN1cHBvcnRl ZCBmb3JtYXRzIChFTlVNRk1UKQo+IGFuZCB1c2Vyc3BhY2UgdGhlbiBzZWxlY3RzIGEgZm9ybWF0 IChTX0ZNVCkgZnJvbSB0aGF0IGxpc3QuCgpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYWJvdXQg SERNSSBlbmNvZGVycyBhbmQgdGhlIERSTS9LTVMgc3Vic3lzdGVtIDotKQoKPiBNb3N0IEhETUkg cmVjZWl2ZXJzIGNhbiBjb252ZXJ0IHRoZSBpbnB1dCB0byB2YXJpb3VzIFJHQi9ZQ2JDciBmb3Jt YXRzLgo+IAo+IERlZXAgY29sb3Igc3VwcG9ydCBmb3IgSERNSSBoYXMgbm90IGJlZW4gYWRkZWQg KHN1cnByaXNpbmdseSBub2JvZHkgbmVlZGVkCj4gaXQgYXBwYXJlbnRseSksIGJ1dCBpdCBpcyBw cmV0dHkgZWFzeTogbmV3IFY0TDJfUElYX0ZNVCBkZWZpbmVzIHNob3VsZCBiZQo+IGFkZGVkIGZv ciB0aG9zZS4KCk5ldyBtZWRpYSBidXMgZm9ybWF0cyBpbiB0aGlzIGNhc2UuCgo+IFdoZW4gdGFs a2luZyBhYm91dCBSR0IvWUNiQ3IgSSBwcmVmZXIgdGhlIHRlcm0gJ2NvbG9yIGVuY29kaW5nJywg c2luY2UKPiB0aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggY29sb3JzcGFjZXMgKHNSR0IuIEFk b2JlUkdCLCBCVC4yMDIwLCBldGMuKQoKLS0gClJlZ2FyZHMsCgpMYXVyZW50IFBpbmNoYXJ0Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwg bWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753870AbdASQp7 (ORCPT ); Thu, 19 Jan 2017 11:45:59 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:51374 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753025AbdASQpS (ORCPT ); Thu, 19 Jan 2017 11:45:18 -0500 From: Laurent Pinchart To: Hans Verkuil Cc: Jose Abreu , Neil Armstrong , dri-devel@lists.freedesktop.org, laurent.pinchart+renesas@ideasonboard.com, kieran.bingham@ideasonboard.com, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org, Hans Verkuil Subject: Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data Date: Thu, 19 Jan 2017 18:45:36 +0200 Message-ID: <41264092.NJkav44OGl@avalon> User-Agent: KMail/4.14.10 (Linux/4.8.6-gentoo; KDE/4.14.24; x86_64; ; ) In-Reply-To: References: <1484656294-6140-1-git-send-email-narmstrong@baylibre.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans and Jose, On Thursday 19 Jan 2017 16:30:57 Hans Verkuil wrote: > On 01/19/17 16:21, Jose Abreu wrote: > > On 18-01-2017 20:49, Laurent Pinchart wrote: > >> Ideally the bridge mode set operation should be extended to take format > >> and colorspace information (or another bridge operation should be created > >> for that purpose, I'm still undecided). As that's quite a big change, I'm > >> fine if you start by passing a fixed format and colorspace through > >> platform data. I would however like the format to use the media bus > >> format codes defined in include/uapi/linux/media-bus-format.h. > >> > >> As far as I'm aware we have no colorspace definitions in DRM, so we would > >> need to fix that. V4L2 handles colorspaces, and the API went through > >> several iterations before we got it working, with stupid mistakes that > >> we don't want to repeat here. > >> > >> Jose pointed to > >> https://patchwork.kernel.org/patch/9495153/ as a starting point, and I > >> would like to point out the format and colorspace are two different > >> things. A colorspace is a combination of an encoding and quantization > >> and transfer functions. Hans Verkuil has researched this topic for V4L2 > >> (see https://gstreamer.freedesktop.org/data/events/gstreamer-> >> conference/2015/Hans Verkuil - Colorspaces and HDMI.pdf and > >> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/colorspaces.html), we > >> *really* want to involve him in this discussion. > >> > >> I believe colorspace information should be shared between V4L2 and DRM > >> the same way we share the media bus formats (We should have done so for > >> 4CCs as well but it's unfortunately too late for that). > > > > Hmm, I am always confusing this :/ So, what I was refering as > > "color space" is in reality the encoding (pixel encoding). In > > HDMI the pixel encoding can be RGB 4:4:4, YCbCr 4:4:4, YCbCr > > 4:2:2 and YCbCr 4:2:0. We also have color depth which can be from > > 8-bit to 16-bit. Besides this there is also colorimetry. There's two separate concepts here, the color encoding and the pixel format. The color encoding defines how non-linear R'G'B' is transformed to non-linear Y'CbCr (or whether to stick to R'G'B' of course). It's a mathematical formula, and along with the quantization defines how the numerical Y'CbCr values are obtained. The pixel format then defines the number of bits per sample, as well as the subsampling factors. The media bus codes thus roughly correspond to pixel formats (although they also define whether the color encoding uses RGB or YCbCr, but don't define the color encoding itself or the quantization method). > > I've used media-bus-format.h to successfully pass information > > across a V4L2 driver but I've used it in BGR24 only, which is RGB > > 4:4:4 8 bit, which in media-bust-format.h would correspond to > > MEDIA_BUS_FMT_BGR888_1X24. So, I don't know exactly what is the > > support for other encodings and what if there's support for color > > depth. If there is then great, but if not then support for this > > should also be added. We have a bunch of YUV media bus formats defined in the kernel (see https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/subdev-formats.html#v4l2-mbus-pixelcode). We're missing some that would be needed here (namely YUV 4:4:4 in 12bpp and I believe the 4:2:0 formats), but it's just a matter of adding new definitions with the related documentation. > > DRM already parses successfully the supported encodings from EDID > > and stores them in a structure. Note that this is the output > > encoding, not the input one. We can still have RGB as input and > > then output at YCbCr using CSC. The missing point is the > > selection of encoding (either from userspace or from some sort of > > automatic mechanism by the kernel). We need to select both the input and output formats and encodings, and, yes, I believe that at least the output format and encoding should come from userspace. > The list of supported encodings for video capture depends on the HW > capabilities. So the driver will list the supported formats (ENUMFMT) > and userspace then selects a format (S_FMT) from that list. Please note that this is about HDMI encoders and the DRM/KMS subsystem :-) > Most HDMI receivers can convert the input to various RGB/YCbCr formats. > > Deep color support for HDMI has not been added (surprisingly nobody needed > it apparently), but it is pretty easy: new V4L2_PIX_FMT defines should be > added for those. New media bus formats in this case. > When talking about RGB/YCbCr I prefer the term 'color encoding', since > this has nothing to do with colorspaces (sRGB. AdobeRGB, BT.2020, etc.) -- Regards, Laurent Pinchart