Message-ID: <20260128-neon-lyrical-pheasant-6cbdf2@houat>
Date: Wed, 28 Jan 2026 13:32:15 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>, 
	Mats Randgaard <matrandg@...co.com>, Alain Volmat <alain.volmat@...s.st.com>, 
	Sakari Ailus <sakari.ailus@...ux.intel.com>, Hans Verkuil <hverkuil@...nel.org>, linux-media@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Hans Verkuil <hans.verkuil@...co.com>, 
	Dave Stevenson <dave.stevenson@...pberrypi.com>
Subject: Re: [PATCH v4 2/4] media: uapi: Introduce MEDIA_BUS_FMT_BGR565_1X16

On Fri, Jan 23, 2026 at 05:34:32PM +0200, Laurent Pinchart wrote:
> On Mon, Dec 08, 2025 at 04:32:33PM +0100, Maxime Ripard wrote:
> > On Mon, Oct 27, 2025 at 01:33:08AM +0200, Laurent Pinchart wrote:
> > > On Mon, Oct 27, 2025 at 01:15:54AM +0200, Laurent Pinchart wrote:
> > > > On Mon, Oct 13, 2025 at 01:01:34PM +0200, Maxime Ripard wrote:
> > > > > MIPI-CSI2 sends its RGB format on the wire with the blue component
> > > > > first, then green, then red. MIPI calls that format "RGB", but by v4l2
> > > > > conventions it would be BGR.
> > > > > 
> > > > > MIPI-CSI2 supports three RGB variants: 444, 555, 565, 666 and 888.
> > > > > 
> > > > > We already have BGR666 and BGR888 media bus formats, we don't have any
> > > > > CSI transceivers using the 444 and 555 variants, but some transceivers
> > > > > use the CSI RGB565 format, while using the RGB565 media bus code.
> > > > > 
> > > > > That's a mistake, but since we don't have a BGR565 media bus code we
> > > > > need to introduce one before fixing it.
> > > > > 
> > > > > Signed-off-by: Maxime Ripard <mripard@...nel.org>
> > > > > ---
> > > > >  .../userspace-api/media/v4l/subdev-formats.rst     | 37 ++++++++++++++++++++++
> > > > >  include/uapi/linux/media-bus-format.h              |  3 +-
> > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > > index 8e92f784abd8123f9ea950f954a60af56ee76dbe..def0d24ef6cdb1a2ec9395af1468f56adf31a8de 100644
> > > > > --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > > +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > > @@ -625,10 +625,47 @@ The following tables list existing packed RGB formats.
> > > > >        - b\ :sub:`4`
> > > > >        - b\ :sub:`3`
> > > > >        - b\ :sub:`2`
> > > > >        - b\ :sub:`1`
> > > > >        - b\ :sub:`0`
> > > > > +    * .. _MEDIA-BUS-FMT-BGR565-1X16:
> > > > > +
> > > > > +      - MEDIA_BUS_FMT_BGR565_1X16
> > > > > +      - 0x1028
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      -
> > > > > +      - 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`
> > > > > +      - r\ :sub:`4`
> > > > > +      - r\ :sub:`3`
> > > > > +      - r\ :sub:`2`
> > > > > +      - r\ :sub:`1`
> > > > > +      - r\ :sub:`0`
> > > > 
> > > > We're definitely in convention territory, because this is not how 16-bit
> > > > RGB data is transmitted over CSI-2. CSI-2 transmits blue first, but
> > > > starts with bit 0, not bit 4.
> > > > 
> > > > Have you explored the alternative of picking the parallel bus code that
> > > > matches the serial order when transmitted with the least significant bit
> > > > first ? That would be MEDIA_BUS_FMT_RGB565_1X16 here, and
> > > > MEDIA_BUS_FMT_RGB888_1X24 for 24-bit RGB.
> > > 
> > > To be clear, media bus codes are a matter of conventions. Some
> > > conventions would be easier to explain that others, and can also be more
> > > consistent with pixel format namings, but at the end of the day they're
> > > all conventions. While saying "pick the media bus code that transmits a
> > > pixel in one clock sample, with the bit order matching LSB-first
> > > transmission" could be the simplest to document, there will be a
> > > mismatch in component orders between the media bus code and the pixel
> > > format in some cases. There may also be more drivers implementing other
> > > conventions, making the transition more difficult.
> > > 
> > > I'll be very busy the upcoming week and will likely not be able to
> > > participate in this discussion in the near future.
> > 
> > For the record, we've discussed it on IRC recently.
> > 
> > The suggestion to have all CSI Data Formats as MEDIA_BUS_FMT_RGB*_1X*
> > variants make sense to me. And we can easily document it, because we
> > could match the first bit transmitted with the least significant bit
> > of a media bus code indeed.
> 
> That's one of the things I like about it, it's consistent and easy to
> document. Glad we agree :-)
> 
> > Thus a sensor using RGB888 would register MEDIA_BUS_FMT_RGB888_1X24.
> > That's indeed the case right now with tc358743:
> > https://elixir.bootlin.com/linux/v6.18/source/drivers/media/i2c/tc358743.c#L1775
> > 
> > Unicam however hardcodes (and validates) that the v4l2 format codes
> > matches the media bus code of the other end:
> > 
> > https://elixir.bootlin.com/linux/v6.18/source/drivers/media/platform/broadcom/bcm2835-unicam.c#L1333
> > 
> > That alone makes total sense, but it has an association between
> > V4l2_PIX_FMT_RGB24 and MEDIA_BUS_FMT_RGB888_1X24, and between
> > V4L2_PIX_FMT_BGR24 and MEDIA_BUS_FMT_BGR888_1X24
> > 
> > https://elixir.bootlin.com/linux/v6.18/source/drivers/media/platform/broadcom/bcm2835-unicam.c#L343
> > 
> > Using the convention you suggested, this association is wrong, and
> > V4L2_PIX_FMT_BGR24 should be associated MEDIA_BUS_FMT_RGB888_1X24. Thus,
> > the red and blue color components are mixed up.
> 
> Correct.
> 
> > I initially tried to fix it in my v1 by removing the RGB24 support
> > https://lore.kernel.org/all/20250606-rpi-unicam-rgb-bgr-fix-v1-1-9930b963f3eb@kernel.org/
> > 
> > This was shot down (rightfully) because it would still be broken.
> > 
> > The second version changed the media bus tc358743 reported:
> > https://lore.kernel.org/all/20250612-csi-bgr-rgb-v1-0-dc8a309118f8@kernel.org/
> > 
> > Dave was against it because it would potentially break userspace, citing
> > Linus that we shouldn't break userspace ever. I understand and somewhat
> > agree with his point, but having two drivers reporting the same data
> > format but with a different meaning is also a way of breaking userspace.
> 
> Yes, I would find that pretty bad, possibly even worse.
> 
> > Anyway. It was then suggested to support both in the tc358743. That's
> > what the second, third and fourth that you commented on worked towards.
> > 
> > https://lore.kernel.org/all/20250911-csi-bgr-rgb-v2-0-e6c6b10c1040@kernel.org/
> > https://lore.kernel.org/all/20250917-csi-bgr-rgb-v3-0-0145571b3aa4@kernel.org/
> > https://lore.kernel.org/all/20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org/
> > 
> > In order to implement your suggestion, I wouldn't to modify tc358743,
> > but would need to modify the association between the v4l2 format and
> > media bus code that unicam has. In a way, it's very similar to my first
> > version that got shot down, and suffers from the same flaws: we could
> > have a userspace application out there hardcoding formats and codes that
> > will get an error.
> > 
> > So I'm not sure your suggestion really works, unless we reevaluate what
> > we mean by breaking userspace. Either way, I don't care, I just want to
> > get pixels in the expected (and documented!) order when using unicam.
> 
> I've lost track of the status of this series and what your current
> suggestion is. Can we standardize on
> 
> - Using MEDIA_BUS_FMT_RGB*

I guess we can do that.

> - Produce V4L2_PIX_FMT_BGR24 from MEDIA_BUS_FMT_RGB888_1X24 in unicam

You called "pretty bad, possibly even worse" to do the exact opposite
(ie, change the bridge media bus to match unicam) because it would break
userspace. Changing the unicam media bus to match the bridge creates the
exact same situation.

The alternative would still be to report both for the bridge, and invert
the current assocation for the v4l2 formats and mbus codes.

> - Possibly implement backward compatibility somewhere (where ?) to avoid
>   regressions, but with a big warning

What would you improve there exactly? It's very clearly in the patches
already, so unless you have some specific comments I'm not really sure
what you want me to do.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists