Re: [PATCH v4 1/2] drm/format-helper: Add conversion from XRGB8888 to BGR888

["andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>]

On Tue, Feb 25, 2025 at 08:37:32AM +0100, Thomas Zimmermann wrote:
> Am 24.02.25 um 15:29 schrieb andriy.shevchenko@linux.intel.com:
> > On Mon, Feb 24, 2025 at 01:38:32PM +0000, Aditya Garg wrote:

...

> > > +static void drm_fb_xrgb8888_to_bgr888_line(void *dbuf, const void *sbuf, unsigned int pixels)
> > Okay the xrgb8888 is the actual pixel format independently on
> > the CPU endianess.
> > 
> > > +{
> > > +	u8 *dbuf8 = dbuf;
> > > +	const __le32 *sbuf32 = sbuf;
> > But here we assume that sbuf is __le32.
> > And I think we may benefit from the __be32 there.
> 
> No, please. XRGB is the logical order. The raw physical byte order for DRM
> formats is always* little endian, hence reversed from the logical one. sbuf
> points to raw memory and is therefore __le32. DRM-format byte order is
> impossible to understand, I know. But that code is correct.

Okay, so it's only about the colour (top-level) layout, the input and output
data is always in little endian?

> *) White lie: there's a DRM format flag signalling physical big endianess.
> That isn't the case here. So nothing here should ever indicate big
> endianess.

But should it indicate the little? To me sounds like neither...

> > > +	unsigned int x;
> > > +	u32 pix;
> > > +
> > > +	for (x = 0; x < pixels; x++) {
> > > +		pix = le32_to_cpu(sbuf32[x]);
> > > +		/* write red-green-blue to output in little endianness */
> > > +		*dbuf8++ = (pix & 0x00ff0000) >> 16;
> > > +		*dbuf8++ = (pix & 0x0000ff00) >> 8;
> > > +		*dbuf8++ = (pix & 0x000000ff) >> 0;
> > 		pix = be32_to_cpu(sbuf[4 * x]) >> 8;
> > 		put_unaligned_le24(pix, &dbuf[3 * x]);
> > 
> > > +	}
> > Or, after all, this __le32 magic might be not needed at all. Wouldn't the below
> > be the equivalent
> > 
> > static void drm_fb_xrgb8888_to_bgr888_line(void *dbuf, const void *sbuf, unsigned int pixels)
> > {
> > 	unsigned int x;
> > 	u32 pix;
> > 
> > 	for (x = 0; x < pixels; x++) {
> > 		/* Read red-green-blue from input in big endianess and... */
> > 		pix = get_unaligned_be24(sbuf + x * 4 + 1);
> > 		/* ...write it to output in little endianness. */
> > 		put_unaligned_le24(pix, dbuf + x * 3);
> > 	}
> > }
> > 
> > The comments can even be dropped as the code quite clear about what's going on.
> > 
> > > +}
> > But it's up to you. I don't know which solution gives better code generation
> > either.

-- 
With Best Regards,
Andy Shevchenko