| Message ID | 20200923024333.920-14-laurent.pinchart@ideasonboard.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [PATCH/RFC,01/16] media: videodev2.h: Remove unneeded comment about 4CC value | expand |
On 23/09/2020 04:43, Laurent Pinchart wrote: > Add three new pixel formats that store RGB data in BGR order with 10, 12 > and 16 bits per component. They are used by the Xilinx Video Frame > Buffer Read/Write IP cores. > > The nomenclature for these new formats follows the 8- and 16-bpp RGB > formats and the DRM format naming conventions, which differs from the > 24- and 32-bpp RGB formats in V4L2. > > As the number of bits per pixel grows quite large, a table with one > column per bit would be difficult to read. These formats are thus > described with one column per byte. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > .../userspace-api/media/v4l/pixfmt-rgb.rst | 68 +++++++++++++++++++ > include/uapi/linux/videodev2.h | 5 ++ > 2 files changed, 73 insertions(+) > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > index 32bfd68af425..2e81d448177e 100644 > --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > @@ -1087,6 +1087,74 @@ order of components as seen in a 24- or 32-bit little endian word. > \endgroup > > > +More Than 8 Bits Per Component > +============================== > + > +These formats store an RGB triplet in four bytes or more. Similarly to the 8- > +and 16-bpp formats, they are named based on the order of the RGB components as > +seen in a word, which is then stored in memory in little endian byte order, and > +on the number of bits for each component. > + > +.. raw:: latex > + > + \begingroup > + \tiny > + \setlength{\tabcolsep}{2pt} > + > +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}| > + > + > +.. flat-table:: RGB Formats With More Than 8 Bits Per Component > + :stub-columns: 0 > + > + * - Identifier > + - Code > + - Byte 0 in memory > + - Byte 1 > + - Byte 2 > + - Byte 3 > + - Byte 4 > + - Byte 5 > + * .. _V4L2-PIX-FMT-XBGR2101010: > + > + - ``V4L2_PIX_FMT_XBGR2101010`` How about naming this: 'X2B10G10R10'. That makes it easier to understand the number of bits assigned to each pixel component. An alternative (but more verbose) would be: XBGR_2_10_10_10. > + - 'XB30' > + > + - R\ :sub:`7-0` > + - G\ :sub:`5-0` R\ :sub:`9-8` > + - B\ :sub:`3-0` G\ :sub:`9-6` > + - `-`\ :sub:`1-0` B\ :sub:`9-4` > + > + - > + * .. _V4L2-PIX-FMT-XBGR4121212: > + > + - ``V4L2_PIX_FMT_XBGR4121212`` X4B12G12R12 > + - 'XB36' > + > + - R\ :sub:`7-0` > + - G\ :sub:`3-0` R\ :sub:`11-8` > + - G\ :sub:`11-4` > + - B\ :sub:`7-0` > + - `-`\ :sub:`3-0` B\ :sub:`11-8` > + > + - > + * .. _V4L2-PIX-FMT-BGR161616: > + > + - ``V4L2_PIX_FMT_BGR161616`` B16G16R16 Regards, Hans > + - 'XB48' > + > + - R\ :sub:`7-0` > + - R\ :sub:`15-8` > + - G\ :sub:`7-0` > + - G\ :sub:`15-8` > + - B\ :sub:`7-0` > + - B\ :sub:`15-8` > + > +.. raw:: latex > + > + \endgroup > + > + > Deprecated RGB Formats > ====================== > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > index 3f5f1cf8d1c0..9181e44c20db 100644 > --- a/include/uapi/linux/videodev2.h > +++ b/include/uapi/linux/videodev2.h > @@ -561,6 +561,11 @@ struct v4l2_pix_format { > #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 */ > > +/* RGB formats (more than 8 bits per component) */ > +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('X', 'B', '3', '0') /* 32 XBGR-2-10-10-10 */ > +#define V4L2_PIX_FMT_XBGR4121212 v4l2_fourcc('X', 'B', '3', '6') /* 40 XBGR-4-12-12-12 */ > +#define V4L2_PIX_FMT_BGR161616 v4l2_fourcc('X', 'B', '4', '8') /* 48 BGR-16-16-16 */ > + > /* Grey formats */ > #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ > #define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */ >
Hi Hans, On Thu, Oct 01, 2020 at 03:44:46PM +0200, Hans Verkuil wrote: > On 23/09/2020 04:43, Laurent Pinchart wrote: > > Add three new pixel formats that store RGB data in BGR order with 10, 12 > > and 16 bits per component. They are used by the Xilinx Video Frame > > Buffer Read/Write IP cores. > > > > The nomenclature for these new formats follows the 8- and 16-bpp RGB > > formats and the DRM format naming conventions, which differs from the > > 24- and 32-bpp RGB formats in V4L2. > > > > As the number of bits per pixel grows quite large, a table with one > > column per bit would be difficult to read. These formats are thus > > described with one column per byte. > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > --- > > .../userspace-api/media/v4l/pixfmt-rgb.rst | 68 +++++++++++++++++++ > > include/uapi/linux/videodev2.h | 5 ++ > > 2 files changed, 73 insertions(+) > > > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > > index 32bfd68af425..2e81d448177e 100644 > > --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > > @@ -1087,6 +1087,74 @@ order of components as seen in a 24- or 32-bit little endian word. > > \endgroup > > > > > > +More Than 8 Bits Per Component > > +============================== > > + > > +These formats store an RGB triplet in four bytes or more. Similarly to the 8- > > +and 16-bpp formats, they are named based on the order of the RGB components as > > +seen in a word, which is then stored in memory in little endian byte order, and > > +on the number of bits for each component. > > + > > +.. raw:: latex > > + > > + \begingroup > > + \tiny > > + \setlength{\tabcolsep}{2pt} > > + > > +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}| > > + > > + > > +.. flat-table:: RGB Formats With More Than 8 Bits Per Component > > + :stub-columns: 0 > > + > > + * - Identifier > > + - Code > > + - Byte 0 in memory > > + - Byte 1 > > + - Byte 2 > > + - Byte 3 > > + - Byte 4 > > + - Byte 5 > > + * .. _V4L2-PIX-FMT-XBGR2101010: > > + > > + - ``V4L2_PIX_FMT_XBGR2101010`` > > How about naming this: 'X2B10G10R10'. That makes it easier to understand the > number of bits assigned to each pixel component. > > An alternative (but more verbose) would be: XBGR_2_10_10_10. Both depart from existing naming conventions, but I think they have merit. I'm not sure which one to pick though. I'll go for the former, but if anyone prefers the latter, that's fine too. > > + - 'XB30' > > + > > + - R\ :sub:`7-0` > > + - G\ :sub:`5-0` R\ :sub:`9-8` > > + - B\ :sub:`3-0` G\ :sub:`9-6` > > + - `-`\ :sub:`1-0` B\ :sub:`9-4` > > + > > + - > > + * .. _V4L2-PIX-FMT-XBGR4121212: > > + > > + - ``V4L2_PIX_FMT_XBGR4121212`` > > X4B12G12R12 > > > + - 'XB36' > > + > > + - R\ :sub:`7-0` > > + - G\ :sub:`3-0` R\ :sub:`11-8` > > + - G\ :sub:`11-4` > > + - B\ :sub:`7-0` > > + - `-`\ :sub:`3-0` B\ :sub:`11-8` > > + > > + - > > + * .. _V4L2-PIX-FMT-BGR161616: > > + > > + - ``V4L2_PIX_FMT_BGR161616`` > > B16G16R16 > > > + - 'XB48' > > + > > + - R\ :sub:`7-0` > > + - R\ :sub:`15-8` > > + - G\ :sub:`7-0` > > + - G\ :sub:`15-8` > > + - B\ :sub:`7-0` > > + - B\ :sub:`15-8` > > + > > +.. raw:: latex > > + > > + \endgroup > > + > > + > > Deprecated RGB Formats > > ====================== > > > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > > index 3f5f1cf8d1c0..9181e44c20db 100644 > > --- a/include/uapi/linux/videodev2.h > > +++ b/include/uapi/linux/videodev2.h > > @@ -561,6 +561,11 @@ struct v4l2_pix_format { > > #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 */ > > > > +/* RGB formats (more than 8 bits per component) */ > > +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('X', 'B', '3', '0') /* 32 XBGR-2-10-10-10 */ > > +#define V4L2_PIX_FMT_XBGR4121212 v4l2_fourcc('X', 'B', '3', '6') /* 40 XBGR-4-12-12-12 */ > > +#define V4L2_PIX_FMT_BGR161616 v4l2_fourcc('X', 'B', '4', '8') /* 48 BGR-16-16-16 */ > > + > > /* Grey formats */ > > #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ > > #define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index 32bfd68af425..2e81d448177e 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -1087,6 +1087,74 @@ order of components as seen in a 24- or 32-bit little endian word. \endgroup +More Than 8 Bits Per Component +============================== + +These formats store an RGB triplet in four bytes or more. Similarly to the 8- +and 16-bpp formats, they are named based on the order of the RGB components as +seen in a word, which is then stored in memory in little endian byte order, and +on the number of bits for each component. + +.. raw:: latex + + \begingroup + \tiny + \setlength{\tabcolsep}{2pt} + +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}| + + +.. flat-table:: RGB Formats With More Than 8 Bits Per Component + :stub-columns: 0 + + * - Identifier + - Code + - Byte 0 in memory + - Byte 1 + - Byte 2 + - Byte 3 + - Byte 4 + - Byte 5 + * .. _V4L2-PIX-FMT-XBGR2101010: + + - ``V4L2_PIX_FMT_XBGR2101010`` + - 'XB30' + + - R\ :sub:`7-0` + - G\ :sub:`5-0` R\ :sub:`9-8` + - B\ :sub:`3-0` G\ :sub:`9-6` + - `-`\ :sub:`1-0` B\ :sub:`9-4` + + - + * .. _V4L2-PIX-FMT-XBGR4121212: + + - ``V4L2_PIX_FMT_XBGR4121212`` + - 'XB36' + + - R\ :sub:`7-0` + - G\ :sub:`3-0` R\ :sub:`11-8` + - G\ :sub:`11-4` + - B\ :sub:`7-0` + - `-`\ :sub:`3-0` B\ :sub:`11-8` + + - + * .. _V4L2-PIX-FMT-BGR161616: + + - ``V4L2_PIX_FMT_BGR161616`` + - 'XB48' + + - R\ :sub:`7-0` + - R\ :sub:`15-8` + - G\ :sub:`7-0` + - G\ :sub:`15-8` + - B\ :sub:`7-0` + - B\ :sub:`15-8` + +.. raw:: latex + + \endgroup + + Deprecated RGB Formats ====================== diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 3f5f1cf8d1c0..9181e44c20db 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -561,6 +561,11 @@ struct v4l2_pix_format { #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 */ +/* RGB formats (more than 8 bits per component) */ +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('X', 'B', '3', '0') /* 32 XBGR-2-10-10-10 */ +#define V4L2_PIX_FMT_XBGR4121212 v4l2_fourcc('X', 'B', '3', '6') /* 40 XBGR-4-12-12-12 */ +#define V4L2_PIX_FMT_BGR161616 v4l2_fourcc('X', 'B', '4', '8') /* 48 BGR-16-16-16 */ + /* Grey formats */ #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ #define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */
Add three new pixel formats that store RGB data in BGR order with 10, 12 and 16 bits per component. They are used by the Xilinx Video Frame Buffer Read/Write IP cores. The nomenclature for these new formats follows the 8- and 16-bpp RGB formats and the DRM format naming conventions, which differs from the 24- and 32-bpp RGB formats in V4L2. As the number of bits per pixel grows quite large, a table with one column per bit would be difficult to read. These formats are thus described with one column per byte. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- .../userspace-api/media/v4l/pixfmt-rgb.rst | 68 +++++++++++++++++++ include/uapi/linux/videodev2.h | 5 ++ 2 files changed, 73 insertions(+)