Message ID | 20230110195331.175103-1-marex@denx.de (mailing list archive) |
---|---|
State | Superseded |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1pFKgy-00EalC-GO; Tue, 10 Jan 2023 19:53:57 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232960AbjAJTxt (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Tue, 10 Jan 2023 14:53:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232670AbjAJTxp (ORCPT <rfc822;linux-media@vger.kernel.org>); Tue, 10 Jan 2023 14:53:45 -0500 Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7B2912D06 for <linux-media@vger.kernel.org>; Tue, 10 Jan 2023 11:53:44 -0800 (PST) Received: from tr.lan (ip-86-49-120-218.bb.vodafone.cz [86.49.120.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 4D62C80CB0; Tue, 10 Jan 2023 20:53:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1673380422; bh=pkq8RXXUt0BEPtVpd5dHqZrWJ4rusDYCUuhOl8p0wvc=; h=From:To:Cc:Subject:Date:From; b=rdFv+WoZvUYmvAZcFDbawGZGLE2CleVhNrsSc3ihfbeb8XOI+pdjFfJTMFAnJXPeQ 7KII+CPnvFlc4efhF0LgEiORpXew8LUU2eK3Seb7kpRHT9/i+hB/W+bk9Ac67cDPCe snFnL1hEl04Hhhfuv3lWO1hiH/DMIim+nO+COgtls4fgvIrKtTAqg7tavQOZPR8M2c UxucGmOxA1++ZUw7aAE0SkROghYz0l1STB/fVX9/izAMqZ+kvBru3bNPLmgF/MMgvg AXCI1tkggMz3FUJsbFRfMg6YRaw3kA21u96tFmAFU5X9MyKcSw5rze/+wN08gl3YoG EAD8iOIKGDCVg== From: Marek Vasut <marex@denx.de> To: linux-media@vger.kernel.org Cc: Marek Vasut <marex@denx.de>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, William Manley <will@williammanley.net> Subject: [PATCH] media: uvcvideo: Add GUID for BGRA/X 8:8:8:8 Date: Tue, 10 Jan 2023 20:53:31 +0100 Message-Id: <20230110195331.175103-1-marex@denx.de> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URI_TRY_3LD autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,URI_TRY_3LD=0.001 autolearn=ham autolearn_force=no |
Series |
media: uvcvideo: Add GUID for BGRA/X 8:8:8:8
|
|
Commit Message
Marek Vasut
Jan. 10, 2023, 7:53 p.m. UTC
The Cypress EZUSB FX3 UVC example can be configured to report pixel
format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for
BGRA/X 8:8:8:8.
The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420.
This seems to be an extension documented in the Microsoft Windows Media
Format SDK[2]. This Media Format SDK defines this GUID as corresponding
to `MEDIASUBTYPE_RGB32`.
Note that in my case, the FX3 UVC can output either channel order,
BGR or RGB or any other mix for that matter. Since Linux commit
1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8")
defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep
this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well.
[1]: https://www.usb.org/document-library/video-class-v15-document-set
[2]: https://learn.microsoft.com/en-us/windows/win32/wmformat/media-type-identifiers
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: William Manley <will@williammanley.net>
---
include/media/v4l2-uvc.h | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
Hi Marek, Thank you for the patch. On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: > The Cypress EZUSB FX3 UVC example can be configured to report pixel > format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for > BGRA/X 8:8:8:8. > > The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. > This seems to be an extension documented in the Microsoft Windows Media > Format SDK[2]. This Media Format SDK defines this GUID as corresponding > to `MEDIASUBTYPE_RGB32`. > > Note that in my case, the FX3 UVC can output either channel order, > BGR or RGB or any other mix for that matter. Since Linux commit > 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") > defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep > this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that indicates the components order precisely. While there's a high chance it maps to a BGR (in the V4L2 nomenclature) format, there would still be two different options for the A or X component. > [1]: https://www.usb.org/document-library/video-class-v15-document-set > [2]: https://learn.microsoft.com/en-us/windows/win32/wmformat/media-type-identifiers > > Signed-off-by: Marek Vasut <marex@denx.de> > --- > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > Cc: William Manley <will@williammanley.net> > --- > include/media/v4l2-uvc.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/media/v4l2-uvc.h b/include/media/v4l2-uvc.h > index f83e31661333b..c10e9086338be 100644 > --- a/include/media/v4l2-uvc.h > +++ b/include/media/v4l2-uvc.h > @@ -99,6 +99,9 @@ > #define UVC_GUID_FORMAT_BGR3 \ > { 0x7d, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \ > 0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70} > +#define UVC_GUID_FORMAT_BGR4 \ > + { 0x7e, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \ > + 0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70} > #define UVC_GUID_FORMAT_M420 \ > { 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \ > 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71} > @@ -266,6 +269,11 @@ static struct uvc_format_desc uvc_fmts[] = { > .guid = UVC_GUID_FORMAT_BGR3, > .fcc = V4L2_PIX_FMT_BGR24, > }, > + { > + .name = "BGRA/X 8:8:8:8 (BGR4)", > + .guid = UVC_GUID_FORMAT_BGR4, > + .fcc = V4L2_PIX_FMT_BGR32, > + }, > { > .name = "H.264", > .guid = UVC_GUID_FORMAT_H264,
On 1/13/23 00:15, Laurent Pinchart wrote: > Hi Marek, Hi, > Thank you for the patch. > > On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: >> The Cypress EZUSB FX3 UVC example can be configured to report pixel >> format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for >> BGRA/X 8:8:8:8. >> >> The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. >> This seems to be an extension documented in the Microsoft Windows Media >> Format SDK[2]. This Media Format SDK defines this GUID as corresponding >> to `MEDIASUBTYPE_RGB32`. >> >> Note that in my case, the FX3 UVC can output either channel order, >> BGR or RGB or any other mix for that matter. Since Linux commit >> 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") >> defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep >> this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. > > I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that > indicates the components order precisely. While there's a high chance it > maps to a BGR (in the V4L2 nomenclature) format, there would still be > two different options for the A or X component. Maybe this ? https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/DirectShow/uncompressed-rgb-video-subtypes.md " Remarks ... For RGB 32, every pixel is an RGBQUAD. Each color is one byte, with a value from 0 to 255, inclusive. The memory layout is: Byte 0 1 2 3 Value Blue Green Red Alpha or Don't Care " Maps to drivers/media/v4l2-core/v4l2-ioctl.c: case V4L2_PIX_FMT_BGR32: descr = "32-bit BGRA/X 8-8-8-8"; break;
Hi Marek, On Fri, Jan 13, 2023 at 02:03:33AM +0100, Marek Vasut wrote: > On 1/13/23 00:15, Laurent Pinchart wrote: > > On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: > >> The Cypress EZUSB FX3 UVC example can be configured to report pixel > >> format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for > >> BGRA/X 8:8:8:8. > >> > >> The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. > >> This seems to be an extension documented in the Microsoft Windows Media > >> Format SDK[2]. This Media Format SDK defines this GUID as corresponding > >> to `MEDIASUBTYPE_RGB32`. > >> > >> Note that in my case, the FX3 UVC can output either channel order, > >> BGR or RGB or any other mix for that matter. Since Linux commit > >> 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") > >> defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep > >> this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. > > > > I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that > > indicates the components order precisely. While there's a high chance it > > maps to a BGR (in the V4L2 nomenclature) format, there would still be > > two different options for the A or X component. > > Maybe this ? > > https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/DirectShow/uncompressed-rgb-video-subtypes.md > > " > Remarks > ... > For RGB 32, every pixel is an RGBQUAD. Each color is one byte, with a > value from 0 to 255, inclusive. The memory layout is: > Byte 0 1 2 3 > Value Blue Green Red Alpha or Don't Care > " > > Maps to > > drivers/media/v4l2-core/v4l2-ioctl.c: case V4L2_PIX_FMT_BGR32: > descr = "32-bit BGRA/X 8-8-8-8"; break; Thank you for digging it up. Looks good to me, except that V4L2_PIX_FMT_BGR32 is deprecated (see https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/pixfmt-rgb.html#deprecated-rgb-formats). You should use V4L2_PIX_FMT_BGRA32 or V4L2_PIX_FMT_BGRX32 instead.
On 1/15/23 22:32, Laurent Pinchart wrote: > Hi Marek, > > On Fri, Jan 13, 2023 at 02:03:33AM +0100, Marek Vasut wrote: >> On 1/13/23 00:15, Laurent Pinchart wrote: >>> On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: >>>> The Cypress EZUSB FX3 UVC example can be configured to report pixel >>>> format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for >>>> BGRA/X 8:8:8:8. >>>> >>>> The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. >>>> This seems to be an extension documented in the Microsoft Windows Media >>>> Format SDK[2]. This Media Format SDK defines this GUID as corresponding >>>> to `MEDIASUBTYPE_RGB32`. >>>> >>>> Note that in my case, the FX3 UVC can output either channel order, >>>> BGR or RGB or any other mix for that matter. Since Linux commit >>>> 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") >>>> defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep >>>> this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. >>> >>> I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that >>> indicates the components order precisely. While there's a high chance it >>> maps to a BGR (in the V4L2 nomenclature) format, there would still be >>> two different options for the A or X component. >> >> Maybe this ? >> >> https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/DirectShow/uncompressed-rgb-video-subtypes.md >> >> " >> Remarks >> ... >> For RGB 32, every pixel is an RGBQUAD. Each color is one byte, with a >> value from 0 to 255, inclusive. The memory layout is: >> Byte 0 1 2 3 >> Value Blue Green Red Alpha or Don't Care >> " >> >> Maps to >> >> drivers/media/v4l2-core/v4l2-ioctl.c: case V4L2_PIX_FMT_BGR32: >> descr = "32-bit BGRA/X 8-8-8-8"; break; > > Thank you for digging it up. Looks good to me, except that > V4L2_PIX_FMT_BGR32 is deprecated (see > https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/pixfmt-rgb.html#deprecated-rgb-formats). > You should use V4L2_PIX_FMT_BGRA32 or V4L2_PIX_FMT_BGRX32 instead. V4L2_PIX_FMT_XBGR32 , right ?
Hi Marek, On Mon, Jan 16, 2023 at 12:45:34AM +0100, Marek Vasut wrote: > On 1/15/23 22:32, Laurent Pinchart wrote: > > On Fri, Jan 13, 2023 at 02:03:33AM +0100, Marek Vasut wrote: > >> On 1/13/23 00:15, Laurent Pinchart wrote: > >>> On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: > >>>> The Cypress EZUSB FX3 UVC example can be configured to report pixel > >>>> format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for > >>>> BGRA/X 8:8:8:8. > >>>> > >>>> The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. > >>>> This seems to be an extension documented in the Microsoft Windows Media > >>>> Format SDK[2]. This Media Format SDK defines this GUID as corresponding > >>>> to `MEDIASUBTYPE_RGB32`. > >>>> > >>>> Note that in my case, the FX3 UVC can output either channel order, > >>>> BGR or RGB or any other mix for that matter. Since Linux commit > >>>> 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") > >>>> defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep > >>>> this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. > >>> > >>> I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that > >>> indicates the components order precisely. While there's a high chance it > >>> maps to a BGR (in the V4L2 nomenclature) format, there would still be > >>> two different options for the A or X component. > >> > >> Maybe this ? > >> > >> https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/DirectShow/uncompressed-rgb-video-subtypes.md > >> > >> " > >> Remarks > >> ... > >> For RGB 32, every pixel is an RGBQUAD. Each color is one byte, with a > >> value from 0 to 255, inclusive. The memory layout is: > >> Byte 0 1 2 3 > >> Value Blue Green Red Alpha or Don't Care > >> " > >> > >> Maps to > >> > >> drivers/media/v4l2-core/v4l2-ioctl.c: case V4L2_PIX_FMT_BGR32: > >> descr = "32-bit BGRA/X 8-8-8-8"; break; > > > > Thank you for digging it up. Looks good to me, except that > > V4L2_PIX_FMT_BGR32 is deprecated (see > > https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/pixfmt-rgb.html#deprecated-rgb-formats). > > You should use V4L2_PIX_FMT_BGRA32 or V4L2_PIX_FMT_BGRX32 instead. > > V4L2_PIX_FMT_XBGR32 , right ? Yes, my bad. 4CCs are awful :-) We could also use V4L2_PIX_FMT_ABGR32, but I don't think a UVC camera would meaningfully produce an alpha channel. I can change the pixel format when applying the patch if this is fine with you.
On 1/16/23 01:32, Laurent Pinchart wrote: > Hi Marek, Hi, > On Mon, Jan 16, 2023 at 12:45:34AM +0100, Marek Vasut wrote: >> On 1/15/23 22:32, Laurent Pinchart wrote: >>> On Fri, Jan 13, 2023 at 02:03:33AM +0100, Marek Vasut wrote: >>>> On 1/13/23 00:15, Laurent Pinchart wrote: >>>>> On Tue, Jan 10, 2023 at 08:53:31PM +0100, Marek Vasut wrote: >>>>>> The Cypress EZUSB FX3 UVC example can be configured to report pixel >>>>>> format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for >>>>>> BGRA/X 8:8:8:8. >>>>>> >>>>>> The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. >>>>>> This seems to be an extension documented in the Microsoft Windows Media >>>>>> Format SDK[2]. This Media Format SDK defines this GUID as corresponding >>>>>> to `MEDIASUBTYPE_RGB32`. >>>>>> >>>>>> Note that in my case, the FX3 UVC can output either channel order, >>>>>> BGR or RGB or any other mix for that matter. Since Linux commit >>>>>> 1b8dc32286a1a ("[media] uvcvideo: Add GUID for BGR 8:8:8") >>>>>> defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep >>>>>> this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. >>>>> >>>>> I'd like to see documentation of the MEDIASUBTYPE_RGB32 format that >>>>> indicates the components order precisely. While there's a high chance it >>>>> maps to a BGR (in the V4L2 nomenclature) format, there would still be >>>>> two different options for the A or X component. >>>> >>>> Maybe this ? >>>> >>>> https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/DirectShow/uncompressed-rgb-video-subtypes.md >>>> >>>> " >>>> Remarks >>>> ... >>>> For RGB 32, every pixel is an RGBQUAD. Each color is one byte, with a >>>> value from 0 to 255, inclusive. The memory layout is: >>>> Byte 0 1 2 3 >>>> Value Blue Green Red Alpha or Don't Care >>>> " >>>> >>>> Maps to >>>> >>>> drivers/media/v4l2-core/v4l2-ioctl.c: case V4L2_PIX_FMT_BGR32: >>>> descr = "32-bit BGRA/X 8-8-8-8"; break; >>> >>> Thank you for digging it up. Looks good to me, except that >>> V4L2_PIX_FMT_BGR32 is deprecated (see >>> https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/pixfmt-rgb.html#deprecated-rgb-formats). >>> You should use V4L2_PIX_FMT_BGRA32 or V4L2_PIX_FMT_BGRX32 instead. >> >> V4L2_PIX_FMT_XBGR32 , right ? > > Yes, my bad. 4CCs are awful :-) > > We could also use V4L2_PIX_FMT_ABGR32, but I don't think a UVC camera > would meaningfully produce an alpha channel. > > I can change the pixel format when applying the patch if this is fine > with you. I sent a V2 with a couple more links for future reference.
diff --git a/include/media/v4l2-uvc.h b/include/media/v4l2-uvc.h index f83e31661333b..c10e9086338be 100644 --- a/include/media/v4l2-uvc.h +++ b/include/media/v4l2-uvc.h @@ -99,6 +99,9 @@ #define UVC_GUID_FORMAT_BGR3 \ { 0x7d, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \ 0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70} +#define UVC_GUID_FORMAT_BGR4 \ + { 0x7e, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \ + 0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70} #define UVC_GUID_FORMAT_M420 \ { 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \ 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71} @@ -266,6 +269,11 @@ static struct uvc_format_desc uvc_fmts[] = { .guid = UVC_GUID_FORMAT_BGR3, .fcc = V4L2_PIX_FMT_BGR24, }, + { + .name = "BGRA/X 8:8:8:8 (BGR4)", + .guid = UVC_GUID_FORMAT_BGR4, + .fcc = V4L2_PIX_FMT_BGR32, + }, { .name = "H.264", .guid = UVC_GUID_FORMAT_H264,