| Message ID | 20221219140139.294245-2-tomi.valkeinen+renesas@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media/drm: renesas: Add new pixel formats | expand |
On 19/12/2022 21:10, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote: >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >> --- >> .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ >> drivers/media/v4l2-core/v4l2-ioctl.c | 3 + >> include/uapi/linux/videodev2.h | 3 + >> 3 files changed, 200 insertions(+) >> >> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >> index 30f51cd33f99..de78cd2dcd73 100644 >> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or >> \normalsize >> >> >> +10 Bits Per Component >> +===================== >> + >> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four >> +bytes. They are named based on the order of the RGB components as seen in a >> +32-bit word, which is then stored in memory in little endian byte order >> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the >> +number of bits for each component. >> + >> +.. raw:: latex >> + >> + \begingroup >> + \tiny >> + \setlength{\tabcolsep}{2pt} >> + >> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| >> + >> + >> +.. flat-table:: RGB Formats 10 Bits Per Color Component >> + :header-rows: 2 >> + :stub-columns: 0 >> + >> + * - Identifier >> + - Code >> + - :cspan:`7` Byte 0 in memory >> + - :cspan:`7` Byte 1 >> + - :cspan:`7` Byte 2 >> + - :cspan:`7` Byte 3 >> + * - >> + - >> + - 7 >> + - 6 >> + - 5 >> + - 4 >> + - 3 >> + - 2 >> + - 1 >> + - 0 >> + >> + - 7 >> + - 6 >> + - 5 >> + - 4 >> + - 3 >> + - 2 >> + - 1 >> + - 0 >> + >> + - 7 >> + - 6 >> + - 5 >> + - 4 >> + - 3 >> + - 2 >> + - 1 >> + - 0 >> + >> + - 7 >> + - 6 >> + - 5 >> + - 4 >> + - 3 >> + - 2 >> + - 1 >> + - 0 >> + * .. _V4L2-PIX-FMT-XBGR2101010: >> + >> + - ``V4L2_PIX_FMT_XBGR2101010`` >> + - 'RX30' >> + >> + - b\ :sub:`5` >> + - b\ :sub:`4` >> + - b\ :sub:`3` >> + - b\ :sub:`2` >> + - b\ :sub:`1` >> + - b\ :sub:`0` >> + - x >> + - x >> + >> + - g\ :sub:`3` >> + - g\ :sub:`2` >> + - g\ :sub:`1` >> + - g\ :sub:`0` >> + - b\ :sub:`9` >> + - b\ :sub:`8` >> + - b\ :sub:`7` >> + - b\ :sub:`6` >> + >> + - r\ :sub:`1` >> + - r\ :sub:`0` >> + - g\ :sub:`9` >> + - g\ :sub:`8` >> + - g\ :sub:`7` >> + - g\ :sub:`6` >> + - g\ :sub:`5` >> + - g\ :sub:`4` >> + >> + - r\ :sub:`9` >> + - r\ :sub:`8` >> + - r\ :sub:`7` >> + - r\ :sub:`6` >> + - r\ :sub:`5` >> + - r\ :sub:`4` >> + - r\ :sub:`3` >> + - r\ :sub:`2` >> + - > > This doesn't match the text above. This would be RGBX2101010. I'm not > sure which format you want, so I don't know if it's the documentation or > the format name that is incorrect. The next two formats also seem > incorrect to me. Right, the text should say big endian instead of little endian. Tomi
Hi Tomi, On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote: > On 19/12/2022 21:10, Laurent Pinchart wrote: > > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote: > >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. > >> > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> > >> --- > >> .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ > >> drivers/media/v4l2-core/v4l2-ioctl.c | 3 + > >> include/uapi/linux/videodev2.h | 3 + > >> 3 files changed, 200 insertions(+) > >> > >> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > >> index 30f51cd33f99..de78cd2dcd73 100644 > >> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > >> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > >> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or > >> \normalsize > >> > >> > >> +10 Bits Per Component > >> +===================== > >> + > >> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four > >> +bytes. They are named based on the order of the RGB components as seen in a > >> +32-bit word, which is then stored in memory in little endian byte order > >> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the > >> +number of bits for each component. > >> + > >> +.. raw:: latex > >> + > >> + \begingroup > >> + \tiny > >> + \setlength{\tabcolsep}{2pt} > >> + > >> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| > >> + > >> + > >> +.. flat-table:: RGB Formats 10 Bits Per Color Component > >> + :header-rows: 2 > >> + :stub-columns: 0 > >> + > >> + * - Identifier > >> + - Code > >> + - :cspan:`7` Byte 0 in memory > >> + - :cspan:`7` Byte 1 > >> + - :cspan:`7` Byte 2 > >> + - :cspan:`7` Byte 3 > >> + * - > >> + - > >> + - 7 > >> + - 6 > >> + - 5 > >> + - 4 > >> + - 3 > >> + - 2 > >> + - 1 > >> + - 0 > >> + > >> + - 7 > >> + - 6 > >> + - 5 > >> + - 4 > >> + - 3 > >> + - 2 > >> + - 1 > >> + - 0 > >> + > >> + - 7 > >> + - 6 > >> + - 5 > >> + - 4 > >> + - 3 > >> + - 2 > >> + - 1 > >> + - 0 > >> + > >> + - 7 > >> + - 6 > >> + - 5 > >> + - 4 > >> + - 3 > >> + - 2 > >> + - 1 > >> + - 0 > >> + * .. _V4L2-PIX-FMT-XBGR2101010: > >> + > >> + - ``V4L2_PIX_FMT_XBGR2101010`` > >> + - 'RX30' > >> + > >> + - b\ :sub:`5` > >> + - b\ :sub:`4` > >> + - b\ :sub:`3` > >> + - b\ :sub:`2` > >> + - b\ :sub:`1` > >> + - b\ :sub:`0` > >> + - x > >> + - x > >> + > >> + - g\ :sub:`3` > >> + - g\ :sub:`2` > >> + - g\ :sub:`1` > >> + - g\ :sub:`0` > >> + - b\ :sub:`9` > >> + - b\ :sub:`8` > >> + - b\ :sub:`7` > >> + - b\ :sub:`6` > >> + > >> + - r\ :sub:`1` > >> + - r\ :sub:`0` > >> + - g\ :sub:`9` > >> + - g\ :sub:`8` > >> + - g\ :sub:`7` > >> + - g\ :sub:`6` > >> + - g\ :sub:`5` > >> + - g\ :sub:`4` > >> + > >> + - r\ :sub:`9` > >> + - r\ :sub:`8` > >> + - r\ :sub:`7` > >> + - r\ :sub:`6` > >> + - r\ :sub:`5` > >> + - r\ :sub:`4` > >> + - r\ :sub:`3` > >> + - r\ :sub:`2` > >> + - > > > > This doesn't match the text above. This would be RGBX2101010. I'm not > > sure which format you want, so I don't know if it's the documentation or > > the format name that is incorrect. The next two formats also seem > > incorrect to me. > > Right, the text should say big endian instead of little endian. No, in big-endian format, you would have, for instance, V4L2_PIX_FMT_XBGR2101010 defined as [x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]] in memory byte order, while the format you want to define is [B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]] The issue here is that 10-bpp formats don't have an integer number of bytes per component. They are thus more similar to the 16-bit RGB formats, where the macro named defined the order in a 16-bit word, which was then stored in little-endian format in memory. For 24-bit and 32-bit formats, we departed from that rule by using the byte memory order in the macro name. For 10-bpp RGB formats we can't do so anymore. The most sensible option is thus, I think, to use the same naming scheme as the 16-bit RGB formats, which incidentaly matches the DRM naming scheme.
On 20/12/2022 16:24, Laurent Pinchart wrote: > Hi Tomi, > > On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote: >> On 19/12/2022 21:10, Laurent Pinchart wrote: >>> On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote: >>>> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. >>>> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >>>> --- >>>> .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ >>>> drivers/media/v4l2-core/v4l2-ioctl.c | 3 + >>>> include/uapi/linux/videodev2.h | 3 + >>>> 3 files changed, 200 insertions(+) >>>> >>>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >>>> index 30f51cd33f99..de78cd2dcd73 100644 >>>> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >>>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst >>>> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or >>>> \normalsize >>>> >>>> >>>> +10 Bits Per Component >>>> +===================== >>>> + >>>> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four >>>> +bytes. They are named based on the order of the RGB components as seen in a >>>> +32-bit word, which is then stored in memory in little endian byte order >>>> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the >>>> +number of bits for each component. >>>> + >>>> +.. raw:: latex >>>> + >>>> + \begingroup >>>> + \tiny >>>> + \setlength{\tabcolsep}{2pt} >>>> + >>>> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| >>>> + >>>> + >>>> +.. flat-table:: RGB Formats 10 Bits Per Color Component >>>> + :header-rows: 2 >>>> + :stub-columns: 0 >>>> + >>>> + * - Identifier >>>> + - Code >>>> + - :cspan:`7` Byte 0 in memory >>>> + - :cspan:`7` Byte 1 >>>> + - :cspan:`7` Byte 2 >>>> + - :cspan:`7` Byte 3 >>>> + * - >>>> + - >>>> + - 7 >>>> + - 6 >>>> + - 5 >>>> + - 4 >>>> + - 3 >>>> + - 2 >>>> + - 1 >>>> + - 0 >>>> + >>>> + - 7 >>>> + - 6 >>>> + - 5 >>>> + - 4 >>>> + - 3 >>>> + - 2 >>>> + - 1 >>>> + - 0 >>>> + >>>> + - 7 >>>> + - 6 >>>> + - 5 >>>> + - 4 >>>> + - 3 >>>> + - 2 >>>> + - 1 >>>> + - 0 >>>> + >>>> + - 7 >>>> + - 6 >>>> + - 5 >>>> + - 4 >>>> + - 3 >>>> + - 2 >>>> + - 1 >>>> + - 0 >>>> + * .. _V4L2-PIX-FMT-XBGR2101010: >>>> + >>>> + - ``V4L2_PIX_FMT_XBGR2101010`` >>>> + - 'RX30' >>>> + >>>> + - b\ :sub:`5` >>>> + - b\ :sub:`4` >>>> + - b\ :sub:`3` >>>> + - b\ :sub:`2` >>>> + - b\ :sub:`1` >>>> + - b\ :sub:`0` >>>> + - x >>>> + - x >>>> + >>>> + - g\ :sub:`3` >>>> + - g\ :sub:`2` >>>> + - g\ :sub:`1` >>>> + - g\ :sub:`0` >>>> + - b\ :sub:`9` >>>> + - b\ :sub:`8` >>>> + - b\ :sub:`7` >>>> + - b\ :sub:`6` >>>> + >>>> + - r\ :sub:`1` >>>> + - r\ :sub:`0` >>>> + - g\ :sub:`9` >>>> + - g\ :sub:`8` >>>> + - g\ :sub:`7` >>>> + - g\ :sub:`6` >>>> + - g\ :sub:`5` >>>> + - g\ :sub:`4` >>>> + >>>> + - r\ :sub:`9` >>>> + - r\ :sub:`8` >>>> + - r\ :sub:`7` >>>> + - r\ :sub:`6` >>>> + - r\ :sub:`5` >>>> + - r\ :sub:`4` >>>> + - r\ :sub:`3` >>>> + - r\ :sub:`2` >>>> + - >>> >>> This doesn't match the text above. This would be RGBX2101010. I'm not >>> sure which format you want, so I don't know if it's the documentation or >>> the format name that is incorrect. The next two formats also seem >>> incorrect to me. >> >> Right, the text should say big endian instead of little endian. > > No, in big-endian format, you would have, for instance, > V4L2_PIX_FMT_XBGR2101010 defined as > > [x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]] > > in memory byte order, while the format you want to define is > > [B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]] Yes, I see your point. > The issue here is that 10-bpp formats don't have an integer number of > bytes per component. They are thus more similar to the 16-bit RGB > formats, where the macro named defined the order in a 16-bit word, which > was then stored in little-endian format in memory. For 24-bit and 32-bit > formats, we departed from that rule by using the byte memory order in > the macro name. For 10-bpp RGB formats we can't do so anymore. The most > sensible option is thus, I think, to use the same naming scheme as the > 16-bit RGB formats, which incidentaly matches the DRM naming scheme. I agree. It wasn't quite clear to me if Hans agreed to that in the patch 7 discussions, but as you say, maybe that's the only option that makes sense. Tomi
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index 30f51cd33f99..de78cd2dcd73 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or \normalsize +10 Bits Per Component +===================== + +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four +bytes. They are named based on the order of the RGB components as seen in a +32-bit word, which is then stored in memory in little endian byte order +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the +number of bits for each component. + +.. raw:: latex + + \begingroup + \tiny + \setlength{\tabcolsep}{2pt} + +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| + + +.. flat-table:: RGB Formats 10 Bits Per Color Component + :header-rows: 2 + :stub-columns: 0 + + * - Identifier + - Code + - :cspan:`7` Byte 0 in memory + - :cspan:`7` Byte 1 + - :cspan:`7` Byte 2 + - :cspan:`7` Byte 3 + * - + - + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + * .. _V4L2-PIX-FMT-XBGR2101010: + + - ``V4L2_PIX_FMT_XBGR2101010`` + - 'RX30' + + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - x + - x + + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`9` + - b\ :sub:`8` + - b\ :sub:`7` + - b\ :sub:`6` + + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + + - r\ :sub:`9` + - r\ :sub:`8` + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - + * .. _V4L2-PIX-FMT-ABGR2101010: + + - ``V4L2_PIX_FMT_ABGR2101010`` + - 'RA30' + + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - a\ :sub:`1` + - a\ :sub:`0` + + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`9` + - b\ :sub:`8` + - b\ :sub:`7` + - b\ :sub:`6` + + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + + - r\ :sub:`9` + - r\ :sub:`8` + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - + * .. _V4L2-PIX-FMT-BGRA1010102: + + - ``V4L2_PIX_FMT_BGRA1010102`` + - 'AR30' + + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`9` + - b\ :sub:`8` + + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + + - a\ :sub:`1` + - a\ :sub:`0` + - r\ :sub:`9` + - r\ :sub:`8` + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - + +.. raw:: latex + + \endgroup + + Deprecated RGB Formats ====================== diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index fddba75d9074..964300deaf62 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) case V4L2_PIX_FMT_BGRX32: descr = "32-bit XBGR 8-8-8-8"; break; case V4L2_PIX_FMT_RGBA32: descr = "32-bit RGBA 8-8-8-8"; break; case V4L2_PIX_FMT_RGBX32: descr = "32-bit RGBX 8-8-8-8"; break; + case V4L2_PIX_FMT_XBGR2101010: descr = "32-bit XBGR 2-10-10-10"; break; + case V4L2_PIX_FMT_ABGR2101010: descr = "32-bit ABGR 2-10-10-10"; break; + case V4L2_PIX_FMT_BGRA1010102: descr = "32-bit BGRA 10-10-10-2"; break; case V4L2_PIX_FMT_GREY: descr = "8-bit Greyscale"; break; case V4L2_PIX_FMT_Y4: descr = "4-bit Greyscale"; break; case V4L2_PIX_FMT_Y6: descr = "6-bit Greyscale"; break; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 29da1f4b4578..877fd61693b8 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -576,6 +576,9 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_RGBX32 v4l2_fourcc('X', 'B', '2', '4') /* 32 RGBX-8-8-8-8 */ #define V4L2_PIX_FMT_ARGB32 v4l2_fourcc('B', 'A', '2', '4') /* 32 ARGB-8-8-8-8 */ #define V4L2_PIX_FMT_XRGB32 v4l2_fourcc('B', 'X', '2', '4') /* 32 XRGB-8-8-8-8 */ +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('R', 'X', '3', '0') /* 32 XBGR-2-10-10-10 */ +#define V4L2_PIX_FMT_ABGR2101010 v4l2_fourcc('R', 'A', '3', '0') /* 32 ABGR-2-10-10-10 */ +#define V4L2_PIX_FMT_BGRA1010102 v4l2_fourcc('A', 'R', '3', '0') /* 32 BGRA-10-10-10-2 */ /* Grey formats */ #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> --- .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ drivers/media/v4l2-core/v4l2-ioctl.c | 3 + include/uapi/linux/videodev2.h | 3 + 3 files changed, 200 insertions(+)