Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Niklas,
On 02/07/2020 23:51, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Mon, May 25, 2020 at 01:31:43PM +0300, Sakari Ailus wrote:
>> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
>>> Bayer formats are used with cameras and contain green, red and blue
>>> components, with alternating lines of red and green, and blue and green
>>> pixels in different orders. For each block of 2x2 pixels there is one
>>> pixel with a red filter, two with a green filter, and one with a blue
>>> filter. The filters can be arranged in different patterns.
>>>
>>> Add DRM fourcc formats to describe the most common Bayer formats. Also
>>> add a modifiers to describe the custom packing layouts used by the Intel
>>> IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
>>> specification.
>>>
>>> Signed-off-by: Niklas Söderlund
>>> ---
>>> * Changes since v1
>>> - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
>>> - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
>>> - Add diagrams for all Bayer formats memory layout.
>>> - Update documentation.
>>> ---
>>> include/uapi/drm/drm_fourcc.h | 205 ++
>>> 1 file changed, 205 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index 8bc0b31597d80737..d07dd24b49bde6c1 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -285,6 +285,73 @@ extern "C" {
>>> #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
>>> non-subsampled Cb (1) and Cr (2) planes */
>>> #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
>>> non-subsampled Cr (1) and Cb (2) planes */
>>>
>>> +/*
>>> + * Bayer formats
>>> + *
>>> + * Bayer formats contain green, red and blue components, with alternating
>>> lines
>>> + * of red and green, and blue and green pixels in different orders. For
>>> each
>>> + * block of 2x2 pixels there is one pixel with a red filter, two with a
>>> green
>>> + * filter, and one with a blue filter. The filters can be arranged in
>>> different
>>> + * patterns.
>>> + *
>>> + * For example, RGGB:
>>> + * row0: RGRGRGRG...
>>> + * row1: GBGBGBGB...
>>> + * row2: RGRGRGRG...
>>> + * row3: GBGBGBGB...
>>> + * ...
>>> + *
>>> + * Vendors have different methods to pack the pixel samples. For this
>>> reason the
>>> + * fourcc only describes pixel sample size and the filter pattern for each
>>> block
>>> + * of 2x2 pixels. A modifier is needed to describe the memory layout.
>>> + *
>>> + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR
>>> may
>>> + * be used to describe a layout where all samples are placed consecutively
>>> in
>>> + * memory. If the sample does not fit inside a single byte each sample is
>>> stored
>>> + * in the minimum number of bytes required. Any unused bits in each sample
>>> are
>>> + * defined as padding bits and set to zero.
>>> + *
>>> + * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
>>> + *
>>> + * 0 row 0 (RGRG)
>>> 31
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0
>>> g0 g0 g0 | 0 0 0 0 0 0 g0 g0 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1
>>> g1 g1 g1 | 0 0 0 0 0 0 g1 g1 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + *
>>> + * 0 row 1 (GBGB)
>>> 31
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0
>>> b0 b0 b0 | 0 0 0 0 0 0 b0 b0 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1
>>> b1 b1 b1 | 0 0 0 0 0 0 b1 b1 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + */
>>> +
>>> +/* 8-bits Bayer formats */
>>> +#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
>>> +#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
>>> +#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
>>> +#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
>>> +
>>> +/* 10-bit Bayer formats */
>>> +#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
>>> +#def
Re: [libcamera-devel] [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Tomasz,
On Fri, Jun 19, 2020 at 01:06:55PM +, Tomasz Figa wrote:
> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in different orders. For each block of 2x2 pixels there is one
> > pixel with a red filter, two with a green filter, and one with a blue
> > filter. The filters can be arranged in different patterns.
> >
> > Add DRM fourcc formats to describe the most common Bayer formats. Also
> > add a modifiers to describe the custom packing layouts used by the Intel
> > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> > specification.
> >
> > Signed-off-by: Niklas Söderlund
> > ---
> > * Changes since v1
> > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> > - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> > - Add diagrams for all Bayer formats memory layout.
> > - Update documentation.
> > ---
> > include/uapi/drm/drm_fourcc.h | 205 ++
> > 1 file changed, 205 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -285,6 +285,73 @@ extern "C" {
> > #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
> > non-subsampled Cb (1) and Cr (2) planes */
> > #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
> > non-subsampled Cr (1) and Cb (2) planes */
> >
> > +/*
> > + * Bayer formats
> > + *
> > + * Bayer formats contain green, red and blue components, with alternating
> > lines
> > + * of red and green, and blue and green pixels in different orders. For
> > each
> > + * block of 2x2 pixels there is one pixel with a red filter, two with a
> > green
> > + * filter, and one with a blue filter. The filters can be arranged in
> > different
> > + * patterns.
> > + *
> > + * For example, RGGB:
> > + * row0: RGRGRGRG...
> > + * row1: GBGBGBGB...
> > + * row2: RGRGRGRG...
> > + * row3: GBGBGBGB...
> > + * ...
> > + *
>
> I wonder if we're operating on the right level of abstraction within this
> proposal.
>
> The sensor itself transfers only sequential pixels, as read
> out from its matrix. Whether a given pixel corresponds to a red, green
> or blue color filter actually depends on the filter layer, which could
> actually vary between integrations of the same sensor. (See Fujifilm
> X-Trans, which uses regular Sony sensors with their own filter pattern
> [1].)
>
> Moreover, the sensor resolution is specified as the number of pixels
> horizontally and the number of lines horizontally, without considering
> the color pattern.
>
> If we consider that, wouldn't the data stream coming from the sensor be
> essentially DRM_FORMAT_R8/R10/R12/etc.?
>
> Then, on top of that, we would have the packing, which I believe is
> defined well in this document +/- being entangled with the Bayer
> pattern.
>
> What do you think?
>
> [1] https://en.wikipedia.org/wiki/Fujifilm_X-Trans_sensor
I think using DRM_FORMAT_R8/R10/R12/... is a good idea. Packing would
indeed be a modifier, and maybe the CFA could even be expressed
separately from the DRM format (4CC + modifier), through a libcamera
property.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [libcamera-devel] [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Emil, On Thu, May 28, 2020 at 04:36:59PM +0100, Emil Velikov wrote: > On Fri, 22 May 2020 at 07:56, Niklas Söderlund wrote: > > > > Bayer formats are used with cameras and contain green, red and blue > > components, with alternating lines of red and green, and blue and green > > pixels in different orders. For each block of 2x2 pixels there is one > > pixel with a red filter, two with a green filter, and one with a blue > > filter. The filters can be arranged in different patterns. > > > > Add DRM fourcc formats to describe the most common Bayer formats. Also > > add a modifiers to describe the custom packing layouts used by the Intel > > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2 > > specification. > > > > Signed-off-by: Niklas Söderlund > > --- > > * Changes since v1 > > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8. > > - Update the fourcc codes passed to fourcc_code() to avoid a conflict. > > - Add diagrams for all Bayer formats memory layout. > > - Update documentation. > > --- > > include/uapi/drm/drm_fourcc.h | 205 ++ > > 1 file changed, 205 insertions(+) > > Where is the user for these new formats - be that kernel or userspace? > Did you forget to update the __drm_format_info() in > drivers/gpu/drm/drm_fourcc.c? The userspace user is here: https://git.linuxtv.org/libcamera.git/tree/ The formats are not used in the DRM subsystem, so I don't think there's a need to update __drm_format_info(). libcamera is standardizing on using DRM 4CCs to ease interoperability with display. We thus need to be able to express camera-specific formats with DRM 4CCs, even if they're not used on the display side. The alternative would be to have custom 4CCs for those formats, but we would then end up risking a 4CC namespace clash. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Sakari,
On Mon, May 25, 2020 at 01:31:43PM +0300, Sakari Ailus wrote:
> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in different orders. For each block of 2x2 pixels there is one
> > pixel with a red filter, two with a green filter, and one with a blue
> > filter. The filters can be arranged in different patterns.
> >
> > Add DRM fourcc formats to describe the most common Bayer formats. Also
> > add a modifiers to describe the custom packing layouts used by the Intel
> > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> > specification.
> >
> > Signed-off-by: Niklas Söderlund
> > ---
> > * Changes since v1
> > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> > - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> > - Add diagrams for all Bayer formats memory layout.
> > - Update documentation.
> > ---
> > include/uapi/drm/drm_fourcc.h | 205 ++
> > 1 file changed, 205 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -285,6 +285,73 @@ extern "C" {
> > #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
> > non-subsampled Cb (1) and Cr (2) planes */
> > #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
> > non-subsampled Cr (1) and Cb (2) planes */
> >
> > +/*
> > + * Bayer formats
> > + *
> > + * Bayer formats contain green, red and blue components, with alternating
> > lines
> > + * of red and green, and blue and green pixels in different orders. For
> > each
> > + * block of 2x2 pixels there is one pixel with a red filter, two with a
> > green
> > + * filter, and one with a blue filter. The filters can be arranged in
> > different
> > + * patterns.
> > + *
> > + * For example, RGGB:
> > + * row0: RGRGRGRG...
> > + * row1: GBGBGBGB...
> > + * row2: RGRGRGRG...
> > + * row3: GBGBGBGB...
> > + * ...
> > + *
> > + * Vendors have different methods to pack the pixel samples. For this
> > reason the
> > + * fourcc only describes pixel sample size and the filter pattern for each
> > block
> > + * of 2x2 pixels. A modifier is needed to describe the memory layout.
> > + *
> > + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR
> > may
> > + * be used to describe a layout where all samples are placed consecutively
> > in
> > + * memory. If the sample does not fit inside a single byte each sample is
> > stored
> > + * in the minimum number of bytes required. Any unused bits in each sample
> > are
> > + * defined as padding bits and set to zero.
> > + *
> > + * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
> > + *
> > + * 0 row 0 (RGRG)
> > 31
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0
> > g0 g0 g0 | 0 0 0 0 0 0 g0 g0 |
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1
> > g1 g1 g1 | 0 0 0 0 0 0 g1 g1 |
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + *
> > + * 0 row 1 (GBGB)
> > 31
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0
> > b0 b0 b0 | 0 0 0 0 0 0 b0 b0 |
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1
> > b1 b1 b1 | 0 0 0 0 0 0 b1 b1 |
> > + * + - - - - - - - - + - - - - - - - - + - - - - -
> > - - - + - - - - - - - - +
> > + */
> > +
> > +/* 8-bits Bayer formats */
> > +#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
> > +#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
> > +#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
> > +#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
> > +
> > +/* 10-bit Bayer formats */
> > +#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
> > +#define DRM_FORMAT_BAYER_GRBG10fourcc_code('G', 'R',
Re: [libcamera-devel] [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Niklas,
On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> Bayer formats are used with cameras and contain green, red and blue
> components, with alternating lines of red and green, and blue and green
> pixels in different orders. For each block of 2x2 pixels there is one
> pixel with a red filter, two with a green filter, and one with a blue
> filter. The filters can be arranged in different patterns.
>
> Add DRM fourcc formats to describe the most common Bayer formats. Also
> add a modifiers to describe the custom packing layouts used by the Intel
> IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> specification.
>
> Signed-off-by: Niklas Söderlund
> ---
> * Changes since v1
> - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> - Add diagrams for all Bayer formats memory layout.
> - Update documentation.
> ---
> include/uapi/drm/drm_fourcc.h | 205 ++
> 1 file changed, 205 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -285,6 +285,73 @@ extern "C" {
> #define DRM_FORMAT_YUV444fourcc_code('Y', 'U', '2', '4') /*
> non-subsampled Cb (1) and Cr (2) planes */
> #define DRM_FORMAT_YVU444fourcc_code('Y', 'V', '2', '4') /*
> non-subsampled Cr (1) and Cb (2) planes */
>
> +/*
> + * Bayer formats
> + *
> + * Bayer formats contain green, red and blue components, with alternating
> lines
> + * of red and green, and blue and green pixels in different orders. For each
> + * block of 2x2 pixels there is one pixel with a red filter, two with a green
> + * filter, and one with a blue filter. The filters can be arranged in
> different
> + * patterns.
> + *
> + * For example, RGGB:
> + * row0: RGRGRGRG...
> + * row1: GBGBGBGB...
> + * row2: RGRGRGRG...
> + * row3: GBGBGBGB...
> + * ...
> + *
I wonder if we're operating on the right level of abstraction within this
proposal.
The sensor itself transfers only sequential pixels, as read
out from its matrix. Whether a given pixel corresponds to a red, green
or blue color filter actually depends on the filter layer, which could
actually vary between integrations of the same sensor. (See Fujifilm
X-Trans, which uses regular Sony sensors with their own filter pattern
[1].)
Moreover, the sensor resolution is specified as the number of pixels
horizontally and the number of lines horizontally, without considering
the color pattern.
If we consider that, wouldn't the data stream coming from the sensor be
essentially DRM_FORMAT_R8/R10/R12/etc.?
Then, on top of that, we would have the packing, which I believe is
defined well in this document +/- being entangled with the Bayer
pattern.
What do you think?
[1] https://en.wikipedia.org/wiki/Fujifilm_X-Trans_sensor
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Niklas, On Fri, 22 May 2020 at 07:56, Niklas Söderlund wrote: > > Bayer formats are used with cameras and contain green, red and blue > components, with alternating lines of red and green, and blue and green > pixels in different orders. For each block of 2x2 pixels there is one > pixel with a red filter, two with a green filter, and one with a blue > filter. The filters can be arranged in different patterns. > > Add DRM fourcc formats to describe the most common Bayer formats. Also > add a modifiers to describe the custom packing layouts used by the Intel > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2 > specification. > > Signed-off-by: Niklas Söderlund > --- > * Changes since v1 > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8. > - Update the fourcc codes passed to fourcc_code() to avoid a conflict. > - Add diagrams for all Bayer formats memory layout. > - Update documentation. > --- > include/uapi/drm/drm_fourcc.h | 205 ++ > 1 file changed, 205 insertions(+) > Where is the user for these new formats - be that kernel or userspace? Did you forget to update the __drm_format_info() in drivers/gpu/drm/drm_fourcc.c? -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Niklas,
Thank you for the update.
On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> Bayer formats are used with cameras and contain green, red and blue
> components, with alternating lines of red and green, and blue and green
> pixels in different orders. For each block of 2x2 pixels there is one
> pixel with a red filter, two with a green filter, and one with a blue
> filter. The filters can be arranged in different patterns.
>
> Add DRM fourcc formats to describe the most common Bayer formats. Also
> add a modifiers to describe the custom packing layouts used by the Intel
> IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> specification.
>
> Signed-off-by: Niklas Söderlund
> ---
> * Changes since v1
> - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> - Add diagrams for all Bayer formats memory layout.
> - Update documentation.
> ---
> include/uapi/drm/drm_fourcc.h | 205 ++
> 1 file changed, 205 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -285,6 +285,73 @@ extern "C" {
> #define DRM_FORMAT_YUV444fourcc_code('Y', 'U', '2', '4') /*
> non-subsampled Cb (1) and Cr (2) planes */
> #define DRM_FORMAT_YVU444fourcc_code('Y', 'V', '2', '4') /*
> non-subsampled Cr (1) and Cb (2) planes */
>
> +/*
> + * Bayer formats
> + *
> + * Bayer formats contain green, red and blue components, with alternating
> lines
> + * of red and green, and blue and green pixels in different orders. For each
> + * block of 2x2 pixels there is one pixel with a red filter, two with a green
> + * filter, and one with a blue filter. The filters can be arranged in
> different
> + * patterns.
> + *
> + * For example, RGGB:
> + * row0: RGRGRGRG...
> + * row1: GBGBGBGB...
> + * row2: RGRGRGRG...
> + * row3: GBGBGBGB...
> + * ...
> + *
> + * Vendors have different methods to pack the pixel samples. For this reason
> the
> + * fourcc only describes pixel sample size and the filter pattern for each
> block
> + * of 2x2 pixels. A modifier is needed to describe the memory layout.
> + *
> + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR
> may
> + * be used to describe a layout where all samples are placed consecutively in
> + * memory. If the sample does not fit inside a single byte each sample is
> stored
> + * in the minimum number of bytes required. Any unused bits in each sample
> are
> + * defined as padding bits and set to zero.
> + *
> + * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
> + *
> + * 0 row 0 (RGRG)
> 31
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0 g0
> g0 g0 | 0 0 0 0 0 0 g0 g0 |
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1 g1
> g1 g1 | 0 0 0 0 0 0 g1 g1 |
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + *
> + * 0 row 1 (GBGB)
> 31
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0 b0
> b0 b0 | 0 0 0 0 0 0 b0 b0 |
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1 b1
> b1 b1 | 0 0 0 0 0 0 b1 b1 |
> + * + - - - - - - - - + - - - - - - - - + - - - - - -
> - - + - - - - - - - - +
> + */
> +
> +/* 8-bits Bayer formats */
> +#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
> +#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
> +#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
> +#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
> +
> +/* 10-bit Bayer formats */
> +#define DRM_FORMAT_BAYER_RGGB10 fourcc_code('R', 'G', '1', '0')
> +#define DRM_FORMAT_BAYER_GRBG10 fourcc_code('G', 'R', '1', '0')
> +#define DRM_FORMAT_BAYER_GBRG10 fourcc_code('G', 'B', '1', '0')
> +#define DRM_FORMAT_BAYER_BGGR10 fourcc_code('B', 'G', '1', '0')
> +
> +/* 12-bit Bayer formats */
> +#define DRM_FORMAT_BAYER_
[PATCH v2] drm/fourcc: Add bayer formats and modifiers
Bayer formats are used with cameras and contain green, red and blue
components, with alternating lines of red and green, and blue and green
pixels in different orders. For each block of 2x2 pixels there is one
pixel with a red filter, two with a green filter, and one with a blue
filter. The filters can be arranged in different patterns.
Add DRM fourcc formats to describe the most common Bayer formats. Also
add a modifiers to describe the custom packing layouts used by the Intel
IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
specification.
Signed-off-by: Niklas Söderlund
---
* Changes since v1
- Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
- Update the fourcc codes passed to fourcc_code() to avoid a conflict.
- Add diagrams for all Bayer formats memory layout.
- Update documentation.
---
include/uapi/drm/drm_fourcc.h | 205 ++
1 file changed, 205 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d80737..d07dd24b49bde6c1 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -285,6 +285,73 @@ extern "C" {
#define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
non-subsampled Cb (1) and Cr (2) planes */
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
non-subsampled Cr (1) and Cb (2) planes */
+/*
+ * Bayer formats
+ *
+ * Bayer formats contain green, red and blue components, with alternating lines
+ * of red and green, and blue and green pixels in different orders. For each
+ * block of 2x2 pixels there is one pixel with a red filter, two with a green
+ * filter, and one with a blue filter. The filters can be arranged in different
+ * patterns.
+ *
+ * For example, RGGB:
+ * row0: RGRGRGRG...
+ * row1: GBGBGBGB...
+ * row2: RGRGRGRG...
+ * row3: GBGBGBGB...
+ * ...
+ *
+ * Vendors have different methods to pack the pixel samples. For this reason
the
+ * fourcc only describes pixel sample size and the filter pattern for each
block
+ * of 2x2 pixels. A modifier is needed to describe the memory layout.
+ *
+ * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR may
+ * be used to describe a layout where all samples are placed consecutively in
+ * memory. If the sample does not fit inside a single byte each sample is
stored
+ * in the minimum number of bytes required. Any unused bits in each sample are
+ * defined as padding bits and set to zero.
+ *
+ * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
+ *
+ * 0 row 0 (RGRG)
31
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0 g0 g0
g0 | 0 0 0 0 0 0 g0 g0 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1 g1 g1
g1 | 0 0 0 0 0 0 g1 g1 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ *
+ * 0 row 1 (GBGB)
31
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0 b0 b0
b0 | 0 0 0 0 0 0 b0 b0 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1 b1 b1
b1 | 0 0 0 0 0 0 b1 b1 |
+ * + - - - - - - - - + - - - - - - - - + - - - - - - -
- + - - - - - - - - +
+ */
+
+/* 8-bits Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
+#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
+#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
+#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
+
+/* 10-bit Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
+#define DRM_FORMAT_BAYER_GRBG10fourcc_code('G', 'R', '1', '0')
+#define DRM_FORMAT_BAYER_GBRG10fourcc_code('G', 'B', '1', '0')
+#define DRM_FORMAT_BAYER_BGGR10fourcc_code('B', 'G', '1', '0')
+
+/* 12-bit Bayer formats */
+#define DRM_FORMAT_BAYER_RGGB12fourcc_code('R', 'G', '1', '2')
+#define DRM_FORMAT_BAYER_GRBG12fourcc_code('G', 'R', '1', '2')
+#define DRM_FORMAT_BAYER_GBRG12fourcc_code('G', 'B', '1', '2')
+#define DRM_FORMAT_BAYER_BGGR12fourcc_code('B', 'G', '1', '2')
+
+/* 14-bit Bayer formats */
+#d
