Message ID | 20230116094032.4389-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 1pHM0i-001G8S-EA; Mon, 16 Jan 2023 09:42:39 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232164AbjAPJmd (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Mon, 16 Jan 2023 04:42:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232029AbjAPJmB (ORCPT <rfc822;linux-media@vger.kernel.org>); Mon, 16 Jan 2023 04:42:01 -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 96741901B for <linux-media@vger.kernel.org>; Mon, 16 Jan 2023 01:41:01 -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 2CF2684F3E; Mon, 16 Jan 2023 10:40:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1673862059; bh=2Z2kMCsq5i+J8ewEsI4JA5Hw0b0vs3rbQ3+drUOHW34=; h=From:To:Cc:Subject:Date:From; b=rdasGdp035y/gSP1ySs1RG9IFV0nxUyuvyHS5OTLdQdrlKuvzd5jVA0uBbb26xqTI Y9JU01d7y+qoYZvkBjMyLgdwJrxOacUmdl4gOuiY3aEd+kQxvfICRJJBjidmZT4HS+ 1pqibbjOzHkGmaWrr5yD9zvSY0wQb/n5cdUJCSJF7McWBjTTkKuU9DcaFOlYseVF5W hdFHQdo1F3mneGknELPpTawvn33Vas2qBlGZKlwHIBScZPnXNMLrf9p/O8PJo7D8bq eAvTfQe8AC1I14KvRQtpwuDqIxUXj6MBqBi7LWrDohEcy2APTvPtJKVSxCf5usAq62 H1TNDRlzOaXEw== 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 v2] media: uvcvideo: Add GUID for BGRA/X 8:8:8:8 Date: Mon, 16 Jan 2023 10:40:32 +0100 Message-Id: <20230116094032.4389-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=-2.7 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 |
[v2] media: uvcvideo: Add GUID for BGRA/X 8:8:8:8
|
|
Commit Message
Marek Vasut
Jan. 16, 2023, 9:40 a.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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32`
has different GUID.
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.
Document [3] also indicates the channel order is BGR.
[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
[3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes
[4] https://gix.github.io/media-types/
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>
---
V2: - Reference document [3] confirming BGR channel order
- Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID
- Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated
---
include/media/v4l2-uvc.h | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
Hi Marek, Thank you for the patch. On Mon, Jan 16, 2023 at 10:40:32AM +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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` > has different GUID. > > 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. > Document [3] also indicates the channel order is BGR. > > [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 > [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes > [4] https://gix.github.io/media-types/ > > Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > Cc: William Manley <will@williammanley.net> > --- > V2: - Reference document [3] confirming BGR channel order > - Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID > - Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated > --- > 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..b010a36fc1d95 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_XBGR32, > + }, > { > .name = "H.264", > .guid = UVC_GUID_FORMAT_H264,
Hi Marek!!! Why do they call MEDIASUBTYPE_RGB32 something that is BRG ? ! Why do WE call XBGR something that is BGRX? !! Besides our insanity, your patch looks sane. Thanks for it :) There are some patches on the queue to remove the format definitions, so your patch might not apply cleanly, I guess Laurent will take care of it Thanks On Mon, 16 Jan 2023 at 11:50, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Marek, > > Thank you for the patch. > > On Mon, Jan 16, 2023 at 10:40:32AM +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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` > > has different GUID. > > > > 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. > > Document [3] also indicates the channel order is BGR. > > > > [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 > > [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes > > [4] https://gix.github.io/media-types/ > > > > Signed-off-by: Marek Vasut <marex@denx.de> > > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ricardo Ribalda <ricardo@ribalda.com> > > > --- > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > > Cc: William Manley <will@williammanley.net> > > --- > > V2: - Reference document [3] confirming BGR channel order > > - Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID > > - Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated > > --- > > 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..b010a36fc1d95 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_XBGR32, > > + }, > > { > > .name = "H.264", > > .guid = UVC_GUID_FORMAT_H264, > > -- > Regards, > > Laurent Pinchart
Hello, (CC'ing Michael) On Mon, Jan 16, 2023 at 02:20:40PM +0100, Ricardo Ribalda wrote: > Hi Marek!!! > > Why do they call MEDIASUBTYPE_RGB32 something that is BRG ? ! > > Why do WE call XBGR something that is BGRX? !! > > Besides our insanity, your patch looks sane. Thanks for it :) > > There are some patches on the queue to remove the format definitions, > so your patch might not apply cleanly, I guess Laurent will take care > of it Ricardo meant [5]. Michael, I'm waiting for Mauro to merge the uvcvideo pull request for v6.3 ([6]). Once done, you can use that as a base branch for your series, and send a pull request to Greg. Could you include Marek's patch, either at the bottom or the top of your series ? Alternatively I can send a v4 of the uvcvideo pull request with this patch included if you prefer. [5] https://lore.kernel.org/linux-media/20221215224514.2344656-1-m.grzeschik@pengutronix.de/ [6] https://lore.kernel.org/linux-media/Y8R0yfSL+1BNi%2Ff3@pendragon.ideasonboard.com/ > On Mon, 16 Jan 2023 at 11:50, Laurent Pinchart wrote: > > On Mon, Jan 16, 2023 at 10:40:32AM +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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` > > > has different GUID. > > > > > > 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. > > > Document [3] also indicates the channel order is BGR. > > > > > > [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 > > > [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes > > > [4] https://gix.github.io/media-types/ > > > > > > Signed-off-by: Marek Vasut <marex@denx.de> > > > > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Reviewed-by: Ricardo Ribalda <ricardo@ribalda.com> > > > > --- > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > > > Cc: William Manley <will@williammanley.net> > > > --- > > > V2: - Reference document [3] confirming BGR channel order > > > - Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID > > > - Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated > > > --- > > > 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..b010a36fc1d95 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_XBGR32, > > > + }, > > > { > > > .name = "H.264", > > > .guid = UVC_GUID_FORMAT_H264,
On 1/16/23 14:20, Ricardo Ribalda wrote: > Hi Marek!!! Hello Ricardo, > Why do they call MEDIASUBTYPE_RGB32 something that is BRG ? ! This I do not know. > Why do WE call XBGR something that is BGRX? !! This is ... sigh. > Besides our insanity, your patch looks sane. Thanks for it :) You're welcome. > There are some patches on the queue to remove the format definitions, > so your patch might not apply cleanly, I guess Laurent will take care > of it I have it in my upstream queue, so I'll rebase it and send V3 if there is any conflict in one of the next linux-next trees. Cheers
Hi! On Mon, Jan 16, 2023 at 04:22:29PM +0200, Laurent Pinchart wrote: >On Mon, Jan 16, 2023 at 02:20:40PM +0100, Ricardo Ribalda wrote: >> Hi Marek!!! >> >> Why do they call MEDIASUBTYPE_RGB32 something that is BRG ? ! >> >> Why do WE call XBGR something that is BGRX? !! >> >> Besides our insanity, your patch looks sane. Thanks for it :) >> >> There are some patches on the queue to remove the format definitions, >> so your patch might not apply cleanly, I guess Laurent will take care >> of it > >Ricardo meant [5]. > >Michael, I'm waiting for Mauro to merge the uvcvideo pull request for >v6.3 ([6]). Once done, you can use that as a base branch for your >series, and send a pull request to Greg. Could you include Marek's >patch, either at the bottom or the top of your series ? Alternatively I >can send a v4 of the uvcvideo pull request with this patch included if >you prefer. > >[5] https://lore.kernel.org/linux-media/20221215224514.2344656-1-m.grzeschik@pengutronix.de/ >[6] https://lore.kernel.org/linux-media/Y8R0yfSL+1BNi%2Ff3@pendragon.ideasonboard.com/ I sure will pick up this patch and create a pull request for my series. Thanks. >> On Mon, 16 Jan 2023 at 11:50, Laurent Pinchart wrote: >> > On Mon, Jan 16, 2023 at 10:40:32AM +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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` >> > > has different GUID. >> > > >> > > 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. >> > > Document [3] also indicates the channel order is BGR. >> > > >> > > [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 >> > > [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes >> > > [4] https://gix.github.io/media-types/ >> > > >> > > Signed-off-by: Marek Vasut <marex@denx.de> >> > >> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> >> Reviewed-by: Ricardo Ribalda <ricardo@ribalda.com> >> >> > > --- >> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> >> > > Cc: William Manley <will@williammanley.net> >> > > --- >> > > V2: - Reference document [3] confirming BGR channel order >> > > - Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID >> > > - Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated >> > > --- >> > > 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..b010a36fc1d95 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_XBGR32, >> > > + }, >> > > { >> > > .name = "H.264", >> > > .guid = UVC_GUID_FORMAT_H264, > >-- >Regards, > >Laurent Pinchart >
Hi Michael, On Sun, Jan 22, 2023 at 01:28:15PM +0100, Michael Grzeschik wrote: > On Mon, Jan 16, 2023 at 04:22:29PM +0200, Laurent Pinchart wrote: > > On Mon, Jan 16, 2023 at 02:20:40PM +0100, Ricardo Ribalda wrote: > >> Hi Marek!!! > >> > >> Why do they call MEDIASUBTYPE_RGB32 something that is BRG ? ! > >> > >> Why do WE call XBGR something that is BGRX? !! > >> > >> Besides our insanity, your patch looks sane. Thanks for it :) > >> > >> There are some patches on the queue to remove the format definitions, > >> so your patch might not apply cleanly, I guess Laurent will take care > >> of it > > > > Ricardo meant [5]. > > > > Michael, I'm waiting for Mauro to merge the uvcvideo pull request for > > v6.3 ([6]). Once done, you can use that as a base branch for your > > series, and send a pull request to Greg. Could you include Marek's > > patch, either at the bottom or the top of your series ? Alternatively I > > can send a v4 of the uvcvideo pull request with this patch included if > > you prefer. > > > > [5] https://lore.kernel.org/linux-media/20221215224514.2344656-1-m.grzeschik@pengutronix.de/ > > [6] https://lore.kernel.org/linux-media/Y8R0yfSL+1BNi%2Ff3@pendragon.ideasonboard.com/ > > I sure will pick up this patch and create a pull request for my series. Mauro has merged the media-uvc-next-20230115 tag from git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git, you can now use it as a base. > >> On Mon, 16 Jan 2023 at 11:50, Laurent Pinchart wrote: > >> > On Mon, Jan 16, 2023 at 10:40:32AM +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`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` > >> > > has different GUID. > >> > > > >> > > 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. > >> > > Document [3] also indicates the channel order is BGR. > >> > > > >> > > [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 > >> > > [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes > >> > > [4] https://gix.github.io/media-types/ > >> > > > >> > > Signed-off-by: Marek Vasut <marex@denx.de> > >> > > >> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > >> > >> Reviewed-by: Ricardo Ribalda <ricardo@ribalda.com> > >> > >> > > --- > >> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > >> > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > >> > > Cc: William Manley <will@williammanley.net> > >> > > --- > >> > > V2: - Reference document [3] confirming BGR channel order > >> > > - Reference document [4] describing MEDIASUBTYPE_ARGB32 with different GUID > >> > > - Use V4L2_PIX_FMT_XBGR32 instead of V4L2_PIX_FMT_BGR32 which is deprecated > >> > > --- > >> > > 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..b010a36fc1d95 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_XBGR32, > >> > > + }, > >> > > { > >> > > .name = "H.264", > >> > > .guid = UVC_GUID_FORMAT_H264,
diff --git a/include/media/v4l2-uvc.h b/include/media/v4l2-uvc.h index f83e31661333b..b010a36fc1d95 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_XBGR32, + }, { .name = "H.264", .guid = UVC_GUID_FORMAT_H264,