From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Marco Felsch <m.felsch@pengutronix.de>, p.zabel@pengutronix.de, slongerbeam@gmail.com, hverkuil-cisco@xs4all.nl, sakari.ailus@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats Date: Thu, 29 Apr 2021 19:53:33 +0300 [thread overview] Message-ID: <YIrkjcuF/+huMotl@pendragon.ideasonboard.com> (raw) In-Reply-To: <20210429104441.3e85d81b@coco.lan> Hi Mauro, On Thu, Apr 29, 2021 at 10:44:41AM +0200, Mauro Carvalho Chehab wrote: > Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu: > > On 21-04-29 04:51, Laurent Pinchart wrote: > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote: > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array > > > > with the interleaved IR pixels looks like: > > > > > > > > | G | R | G | B | ... > > > > +----+----+----+----+--- > > > > | IR | G | IR | G | ... > > > > +----+----+----+----+--- > > > > | G | B | G | R | ... > > > > +----+----+----+----+--- > > > > | IR | G | IR | G | ... > > > > +----+----+----+----+--- > > > > | .. | .. | .. | .. | .. > > > > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf > > > > > > I think we're reaching a limit of the media bus codes model here, due to > > > a historical mistake. The four possible Bayer patterns, times the > > > different number of bits per pixel, creates a lot of media bus codes, > > > and drivers for CSI-2 receivers and IP cores further down the pipeline > > > have to support them all. > > > > That's correct but it is not bayer related. > > Err... there are two separate things here: > > 1) for the uAPI part, we're not even close to the limit of a 4-bytes > fourcc; > > 2) the kAPI is currently sharing the same fourcc from the uAPI, > because it is a lot simpler than doing something different. Please note that we're talking about media bus codes here, not pixel formats. Both are part of the UAPI though, and pixel formats suffer from a similar issue, but I'd like to focus on the media bus codes first. > Yet, nothing prevents that the kAPI could be improved in order to > better describe each format, provided that: > > 1. there will be a 1:1 mapping with the uAPI. > In other words, it would be possible to write a function that > would convert a "struct foo" from/to a 32-bits fourcc; > > 2. such new kAPI should be optional, as usually only drivers > for hardware with ISP (plus the UVC driver) would be flexible > enough to allow random formats. For the rest, the bridges are > typically limited to support only a few formats, so it doesn't > make sense to modify existing drivers to use such new kAPI. > > Ok, someone has to come up with a proposal about what a "struct foo" > would contain. On a real quick brainstorm, something like this could > be a start: > > enum v4l2_pixformat_type { > VIDEO_PIXFORMAT_RGB, > VIDEO_PIXFORMAT_YUV, > VIDEO_PIXFORMAT_COMPRESSED, > VIDEO_PIXFORMAT_BAYER_RGB, > VIDEO_PIXFORMAT_BAYER_RGB_IR, > }; > > struct v4l2_pixformat_desc { > enum v4l2_pixformat_type pixfmt_type; > bool is_packed; > int bits_per_component; > > union { > enum v4l2_pixformat_rgb_order rgb_order; > enum v4l2_pixformat_yuv_order yuv_order; > enum v4l2_pixformat_bayer_rgb_order bayer_rgb_order; > enum v4l2_pixformat_bayer_rgb_ir_order bayer_rgb_ir_order; > enum v4l2_pixformat_compress_type compress_type; > }; > ... > }; > > Btw, I remember someone suggested a model similar to that in the past, > shared with DRM. Well, I don't think it would be easy to share > an internal subsystem-specific kAPI like that with other subsystems, > as this is the kind of thing that people will change from time to time, > and coordinating something like that can be painful, but we can try > to fork the model applied to DRM on media. For instance, I doubt that > Bayer RGB + IR would make any sense for DRM drivers. -- Regards, Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Marco Felsch <m.felsch@pengutronix.de>, p.zabel@pengutronix.de, slongerbeam@gmail.com, hverkuil-cisco@xs4all.nl, sakari.ailus@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats Date: Thu, 29 Apr 2021 19:53:33 +0300 [thread overview] Message-ID: <YIrkjcuF/+huMotl@pendragon.ideasonboard.com> (raw) In-Reply-To: <20210429104441.3e85d81b@coco.lan> Hi Mauro, On Thu, Apr 29, 2021 at 10:44:41AM +0200, Mauro Carvalho Chehab wrote: > Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu: > > On 21-04-29 04:51, Laurent Pinchart wrote: > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote: > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array > > > > with the interleaved IR pixels looks like: > > > > > > > > | G | R | G | B | ... > > > > +----+----+----+----+--- > > > > | IR | G | IR | G | ... > > > > +----+----+----+----+--- > > > > | G | B | G | R | ... > > > > +----+----+----+----+--- > > > > | IR | G | IR | G | ... > > > > +----+----+----+----+--- > > > > | .. | .. | .. | .. | .. > > > > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf > > > > > > I think we're reaching a limit of the media bus codes model here, due to > > > a historical mistake. The four possible Bayer patterns, times the > > > different number of bits per pixel, creates a lot of media bus codes, > > > and drivers for CSI-2 receivers and IP cores further down the pipeline > > > have to support them all. > > > > That's correct but it is not bayer related. > > Err... there are two separate things here: > > 1) for the uAPI part, we're not even close to the limit of a 4-bytes > fourcc; > > 2) the kAPI is currently sharing the same fourcc from the uAPI, > because it is a lot simpler than doing something different. Please note that we're talking about media bus codes here, not pixel formats. Both are part of the UAPI though, and pixel formats suffer from a similar issue, but I'd like to focus on the media bus codes first. > Yet, nothing prevents that the kAPI could be improved in order to > better describe each format, provided that: > > 1. there will be a 1:1 mapping with the uAPI. > In other words, it would be possible to write a function that > would convert a "struct foo" from/to a 32-bits fourcc; > > 2. such new kAPI should be optional, as usually only drivers > for hardware with ISP (plus the UVC driver) would be flexible > enough to allow random formats. For the rest, the bridges are > typically limited to support only a few formats, so it doesn't > make sense to modify existing drivers to use such new kAPI. > > Ok, someone has to come up with a proposal about what a "struct foo" > would contain. On a real quick brainstorm, something like this could > be a start: > > enum v4l2_pixformat_type { > VIDEO_PIXFORMAT_RGB, > VIDEO_PIXFORMAT_YUV, > VIDEO_PIXFORMAT_COMPRESSED, > VIDEO_PIXFORMAT_BAYER_RGB, > VIDEO_PIXFORMAT_BAYER_RGB_IR, > }; > > struct v4l2_pixformat_desc { > enum v4l2_pixformat_type pixfmt_type; > bool is_packed; > int bits_per_component; > > union { > enum v4l2_pixformat_rgb_order rgb_order; > enum v4l2_pixformat_yuv_order yuv_order; > enum v4l2_pixformat_bayer_rgb_order bayer_rgb_order; > enum v4l2_pixformat_bayer_rgb_ir_order bayer_rgb_ir_order; > enum v4l2_pixformat_compress_type compress_type; > }; > ... > }; > > Btw, I remember someone suggested a model similar to that in the past, > shared with DRM. Well, I don't think it would be easy to share > an internal subsystem-specific kAPI like that with other subsystems, > as this is the kind of thing that people will change from time to time, > and coordinating something like that can be painful, but we can try > to fork the model applied to DRM on media. For instance, I doubt that > Bayer RGB + IR would make any sense for DRM drivers. -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-29 16:53 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-27 12:06 [PATCH 0/6] Add new bayer ir formats Marco Felsch 2021-04-27 12:06 ` Marco Felsch 2021-04-27 12:06 ` [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats Marco Felsch 2021-04-27 12:06 ` Marco Felsch 2021-04-29 1:51 ` Laurent Pinchart 2021-04-29 1:51 ` Laurent Pinchart 2021-04-29 7:49 ` Marco Felsch 2021-04-29 7:49 ` Marco Felsch 2021-04-29 8:44 ` Mauro Carvalho Chehab 2021-04-29 8:44 ` Mauro Carvalho Chehab 2021-04-29 16:53 ` Laurent Pinchart [this message] 2021-04-29 16:53 ` Laurent Pinchart 2021-04-30 12:44 ` Mauro Carvalho Chehab 2021-04-30 12:44 ` Mauro Carvalho Chehab 2021-04-29 22:14 ` Laurent Pinchart 2021-04-29 22:14 ` Laurent Pinchart 2021-04-30 6:51 ` Marco Felsch 2021-04-30 6:51 ` Marco Felsch 2021-04-30 12:18 ` Laurent Pinchart 2021-04-30 12:18 ` Laurent Pinchart 2021-04-30 12:51 ` Mauro Carvalho Chehab 2021-04-30 12:51 ` Mauro Carvalho Chehab 2021-04-30 12:58 ` Laurent Pinchart 2021-04-30 12:58 ` Laurent Pinchart 2023-02-08 19:44 ` Marco Felsch 2023-02-08 19:44 ` Marco Felsch 2023-02-09 9:49 ` Laurent Pinchart 2023-02-09 9:49 ` Laurent Pinchart 2021-04-27 12:06 ` [PATCH 2/6] media: v4l: Add definition for bayered IR formats Marco Felsch 2021-04-27 12:06 ` Marco Felsch 2021-04-29 1:45 ` Laurent Pinchart 2021-04-29 1:45 ` Laurent Pinchart 2021-04-29 7:07 ` Marco Felsch 2021-04-29 7:07 ` Marco Felsch 2021-04-27 12:06 ` [PATCH 3/6] media: v4l2-ioctl.c: add V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG to v4l_fill_fmtdesc Marco Felsch 2021-04-27 12:06 ` Marco Felsch 2021-04-27 12:06 ` [PATCH 4/6] media: video-mux: add new SGRGB_IGIG_GBGR_IGIG format support Marco Felsch 2021-04-27 12:06 ` Marco Felsch 2021-04-27 12:07 ` [PATCH 5/6] gpu: ipu-v3: add custom " Marco Felsch 2021-04-27 12:07 ` Marco Felsch 2021-04-27 12:07 ` [PATCH 6/6] media: imx: csi: " Marco Felsch 2021-04-27 12:07 ` Marco Felsch 2021-04-27 12:09 ` [PATCH 0/6] Add new bayer ir formats Marco Felsch 2021-04-27 12:09 ` Marco Felsch 2022-11-24 14:49 ` Hans Verkuil 2022-11-24 14:49 ` Hans Verkuil
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YIrkjcuF/+huMotl@pendragon.ideasonboard.com \ --to=laurent.pinchart@ideasonboard.com \ --cc=hverkuil-cisco@xs4all.nl \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-media@vger.kernel.org \ --cc=m.felsch@pengutronix.de \ --cc=mchehab@kernel.org \ --cc=p.zabel@pengutronix.de \ --cc=sakari.ailus@linux.intel.com \ --cc=slongerbeam@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.