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@xxxxxxxxxxxxxxxx>
> >> ---
> >> .../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.
--
Regards,
Laurent Pinchart
