From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A91B43FCC; Wed, 4 Feb 2026 00:52:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770166334; cv=none; b=nxjGZhOJXTlCdZZ7Bt/00bc3mebUUYxH4iG8djap0R8hx8VOoZKta0Ger0Nxpem+6UiZfqcbH4p+Q0hKoBXsBh2m55A7gRGSGgEtqHIS5Wdgf9/s0JLkbG4sXwVq63yAhTx2c+CwVDkEnDRnw4UOgzmAeRsQQqD13hNiC6LsRfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770166334; c=relaxed/simple; bh=uI3Xqr9pjtdnjjvvil1Jo+EKjUfUZX4BVVpeBsW/sC8=; h=Content-Type:MIME-Version:In-Reply-To:References:Subject:From:Cc: To:Date:Message-ID; b=Na8weAwJgqt3VrwSLmA6WhTDQnUjb5TQr/8OxBffwYowaszXsFj9WUeIdtqNLzj2f2ptwTNvfULydcLILJOrjq7bhy84r5Y5ECdIDGm/3vHAwWI95D63Bb4srclHeUto4SZX93HSdYtpOB/9KvUhDbTsQ9AvThuEUyNtbd5wi1g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=PfLIRpsR; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="PfLIRpsR" Received: from mail.ideasonboard.com (unknown [IPv6:2401:4900:1c67:86fa:bf02:d5f1:808c:8622]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 89EC23A4; Wed, 4 Feb 2026 01:51:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1770166289; bh=uI3Xqr9pjtdnjjvvil1Jo+EKjUfUZX4BVVpeBsW/sC8=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=PfLIRpsRJjuMJwEOxQFowot+TuC0YCrrhJDk/frTlsA9QlPIemZQGbPLT1rvEb6Uf 0UJ2xNknIm2cBp4a0vFDMzeLjWBKfBipHIOH3gFBCkfWRycOZf5bLNBRloPzZlEBIJ 3B6fhev1dnsOS95AyPOptdGmStYCkXvaN7YGWb1s= Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260203234354.GD133801@killaraus> References: <20251013-csi-bgr-rgb-v4-2-55eab2caa69f@kernel.org> <20251026233308.GC9719@pendragon.ideasonboard.com> <20251208-powerful-penguin-of-reputation-ffdc5c@houat> <20260123153432.GA415966@killaraus> <20260128-neon-lyrical-pheasant-6cbdf2@houat> <20260128131903.GC3210848@killaraus> <177001699568.9154.17517527570808307498@freya> <20260202093105.GC3374091@killaraus> <177002946028.9154.2512834530413257039@freya> <20260203234354.GD133801@killaraus> Subject: Re: [PATCH v4 2/4] media: uapi: Introduce MEDIA_BUS_FMT_BGR565_1X16 From: Jai Luthra Cc: Maxime Ripard , Mauro Carvalho Chehab , Mats Randgaard , Alain Volmat , Sakari Ailus , Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Hans Verkuil , Dave Stevenson To: Laurent Pinchart Date: Wed, 04 Feb 2026 06:22:05 +0530 Message-ID: <177016632523.9154.6485752908896894612@freya> User-Agent: alot/0.12.dev62+gb9d6144a6 Quoting Laurent Pinchart (2026-02-04 05:13:54) > On Mon, Feb 02, 2026 at 04:21:00PM +0530, Jai Luthra wrote: > > Quoting Laurent Pinchart (2026-02-02 15:01:05) > > > On Mon, Feb 02, 2026 at 12:53:15PM +0530, Jai Luthra wrote: > > > > Quoting Laurent Pinchart (2026-01-28 18:49:03) > > > > > On Wed, Jan 28, 2026 at 01:32:15PM +0100, Maxime Ripard wrote: > > > > > > On Fri, Jan 23, 2026 at 05:34:32PM +0200, Laurent Pinchart wrot= e: > > > > > > > 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 Pinchar= t 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 b= lue component > > > > > > > > > > > first, then green, then red. MIPI calls that format "= RGB", but by v4l2 > > > > > > > > > > > conventions it would be BGR. > > > > > > > > > > >=20 > > > > > > > > > > > MIPI-CSI2 supports three RGB variants: 444, 555, 565,= 666 and 888. > > > > > > > > > > >=20 > > > > > > > > > > > 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 med= ia bus code. > > > > > > > > > > >=20 > > > > > > > > > > > That's a mistake, but since we don't have a BGR565 me= dia bus code we > > > > > > > > > > > need to introduce one before fixing it. > > > > > > > > > > >=20 > > > > > > > > > > > Signed-off-by: Maxime Ripard > > > > > > > > > > > --- > > > > > > > > > > > .../userspace-api/media/v4l/subdev-formats.rst |= 37 ++++++++++++++++++++++ > > > > > > > > > > > include/uapi/linux/media-bus-format.h |= 3 +- > > > > > > > > > > > 2 files changed, 39 insertions(+), 1 deletion(-) > > > > > > > > > > >=20 > > > > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/su= bdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst > > > > > > > > > > > index 8e92f784abd8123f9ea950f954a60af56ee76dbe..def0d= 24ef6cdb1a2ec9395af1468f56adf31a8de 100644 > > > > > > > > > > > --- a/Documentation/userspace-api/media/v4l/subdev-fo= rmats.rst > > > > > > > > > > > +++ b/Documentation/userspace-api/media/v4l/subdev-fo= rmats.rst > > > > > > > > > > > @@ -625,10 +625,47 @@ The following tables list exist= ing 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` > > > > > > > > > >=20 > > > > > > > > > > We're definitely in convention territory, because this = is not how 16-bit > > > > > > > > > > RGB data is transmitted over CSI-2. CSI-2 transmits blu= e first, but > > > > > > > > > > starts with bit 0, not bit 4. > > > > > > > > > >=20 > > > > > > > > > > Have you explored the alternative of picking the parall= el bus code that > > > > > > > > > > matches the serial order when transmitted with the leas= t significant bit > > > > > > > > > > first ? That would be MEDIA_BUS_FMT_RGB565_1X16 here, a= nd > > > > > > > > > > MEDIA_BUS_FMT_RGB888_1X24 for 24-bit RGB. > > > > > > > > >=20 > > > > > > > > > To be clear, media bus codes are a matter of conventions.= Some > > > > > > > > > conventions would be easier to explain that others, and c= an also be more > > > > > > > > > consistent with pixel format namings, but at the end of t= he day they're > > > > > > > > > all conventions. While saying "pick the media bus code th= at transmits a > > > > > > > > > pixel in one clock sample, with the bit order matching LS= B-first > > > > > > > > > transmission" could be the simplest to document, there wi= ll be a > > > > > > > > > mismatch in component orders between the media bus code a= nd the pixel > > > > > > > > > format in some cases. There may also be more drivers impl= ementing other > > > > > > > > > conventions, making the transition more difficult. > > > > > > > > >=20 > > > > > > > > > I'll be very busy the upcoming week and will likely not b= e able to > > > > > > > > > participate in this discussion in the near future. > > > > > > > >=20 > > > > > > > > For the record, we've discussed it on IRC recently. > > > > > > > >=20 > > > > > > > > The suggestion to have all CSI Data Formats as MEDIA_BUS_FM= T_RGB*_1X* > > > > > > > > variants make sense to me. And we can easily document it, b= ecause we > > > > > > > > could match the first bit transmitted with the least signif= icant bit > > > > > > > > of a media bus code indeed. > > > > > > >=20 > > > > > > > That's one of the things I like about it, it's consistent and= easy to > > > > > > > document. Glad we agree :-) > > > > > > >=20 > > > > > > > > Thus a sensor using RGB888 would register MEDIA_BUS_FMT_RGB= 888_1X24. > > > > > > > > That's indeed the case right now with tc358743: > > > > > > > > https://elixir.bootlin.com/linux/v6.18/source/drivers/media= /i2c/tc358743.c#L1775 > > > > > > > >=20 > > > > > > > > Unicam however hardcodes (and validates) that the v4l2 form= at codes > > > > > > > > matches the media bus code of the other end: > > > > > > > >=20 > > > > > > > > https://elixir.bootlin.com/linux/v6.18/source/drivers/media= /platform/broadcom/bcm2835-unicam.c#L1333 > > > > > > > >=20 > > > > > > > > That alone makes total sense, but it has an association bet= ween > > > > > > > > V4l2_PIX_FMT_RGB24 and MEDIA_BUS_FMT_RGB888_1X24, and betwe= en > > > > > > > > V4L2_PIX_FMT_BGR24 and MEDIA_BUS_FMT_BGR888_1X24 > > > > > > > >=20 > > > > > > > > https://elixir.bootlin.com/linux/v6.18/source/drivers/media= /platform/broadcom/bcm2835-unicam.c#L343 > > > > > > > >=20 > > > > > > > > Using the convention you suggested, this association is wro= ng, and > > > > > > > > V4L2_PIX_FMT_BGR24 should be associated MEDIA_BUS_FMT_RGB88= 8_1X24. Thus, > > > > > > > > the red and blue color components are mixed up. > > > > > > >=20 > > > > > > > Correct. > > > > > > >=20 > > > > > > > > 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/ > > > > > > > >=20 > > > > > > > > This was shot down (rightfully) because it would still be b= roken. > > > > > > > >=20 > > > > > > > > The second version changed the media bus tc358743 reported: > > > > > > > > https://lore.kernel.org/all/20250612-csi-bgr-rgb-v1-0-dc8a3= 09118f8@kernel.org/ > > > > > > > >=20 > > > > > > > > Dave was against it because it would potentially break user= space, 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 breaki= ng userspace. > > > > > > >=20 > > > > > > > Yes, I would find that pretty bad, possibly even worse. > > > > > > >=20 > > > > > > > > Anyway. It was then suggested to support both in the tc3587= 43. That's > > > > > > > > what the second, third and fourth that you commented on wor= ked towards. > > > > > > > >=20 > > > > > > > > https://lore.kernel.org/all/20250911-csi-bgr-rgb-v2-0-e6c6b= 10c1040@kernel.org/ > > > > > > > > https://lore.kernel.org/all/20250917-csi-bgr-rgb-v3-0-01455= 71b3aa4@kernel.org/ > > > > > > > > https://lore.kernel.org/all/20251013-csi-bgr-rgb-v4-0-55eab= 2caa69f@kernel.org/ > > > > > > > >=20 > > > > > > > > In order to implement your suggestion, I wouldn't to modify= tc358743, > > > > > > > > but would need to modify the association between the v4l2 f= ormat 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 a= nd codes that > > > > > > > > will get an error. > > > > > > > >=20 > > > > > > > > So I'm not sure your suggestion really works, unless we ree= valuate 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 usi= ng unicam. > > > > > > >=20 > > > > > > > I've lost track of the status of this series and what your cu= rrent > > > > > > > suggestion is. Can we standardize on > > > > > > >=20 > > > > > > > - Using MEDIA_BUS_FMT_RGB* > > > > > >=20 > > > > > > I guess we can do that. > > > > > >=20 > > > > > > > - Produce V4L2_PIX_FMT_BGR24 from MEDIA_BUS_FMT_RGB888_1X24 i= n unicam > > > > > >=20 > > > > > > You called "pretty bad, possibly even worse" to do the exact op= posite > > > > > > (ie, change the bridge media bus to match unicam) because it wo= uld break > > > > > > userspace. Changing the unicam media bus to match the bridge cr= eates the > > > > > > exact same situation. > > > > > >=20 > > > > > > The alternative would still be to report both for the bridge, a= nd invert > > > > > > the current assocation for the v4l2 formats and mbus codes. > > > > > >=20 > > > > > > > - Possibly implement backward compatibility somewhere (where = ?) to avoid > > > > > > > regressions, but with a big warning > > > > > >=20 > > > > > > What would you improve there exactly? It's very clearly in the = patches > > > > > > already, so unless you have some specific comments I'm not real= ly sure > > > > > > what you want me to do. > > > > >=20 > > > > > If we standardize on MEDIA_BUS_FMT_RGB*, then the issue is in the= unicam > > > > > driver, not in the tc358743 driver. Is it possible to implement t= he > > > > > backward compatibility (with a warning) in unicam instead of tc35= 8743 ? > > > >=20 > > > > Not just unicam. TI's CSI driver (j721e-csi2rx.c) also uses: > > > >=20 > > > > V4L2_PIX_FMT_XBGR32 for MEDIA_BUS_FMT_RGB888_1X24 (and vice versa) > > >=20 > > > That is not necessarily wrong. The mapping between media bus codes and > > > pixel formats is device-dependent. Does the upstream j721e-csi2rx dri= ver > > > map MEDIA_BUS_FMT_RGB888_1X24 to V4L2_PIX_FMT_XBGR32 but actually wri= tes > > > a different pixel format to memory ? > >=20 > > From the TRM, MIPI RGB888 unpacks to: > > BYTE0 BYTE1 BYTE2 BYTE3 =20 > > BBBBBBBB GGGGGGGG RRRRRRRR 00000000 =20 > >=20 > > Which is V4L2_PIX_FMT_XBGR32 I believe. >=20 > Correct, it's V4L2_PIX_FMT_XBGR32. Where's the problem ? The mapping > between a media bus code and a pixel format is device-dependent, > j721e-csi2rx and unicam don't have to use the same mapping. Ah my bad, I misread the unicam driver, and thought you were suggesting changing MEDIA_BUS_FMT_RGB888_1X24 to no longer map to the default bit order of MIPI CSI2 RGB888 datatype. Sorry for the confusion. >=20 > > > > (my 2 cents) It's better to have backward compatibility in drivers = that > > > > currently don't follow the Media documentation. I agree the docs are > > > > confusing, they tripped me up too, but there are already userspace > > > > scripts/applications that TI / beagle users use that follow those c= onfusing > > > > docs :) >=20 > --=20 > Regards, >=20 > Laurent Pinchart