[PATCH v3] drm/plane: Add documentation about software color conversion.

[Simon Ser]

On Friday, September 8th, 2023 at 22:22, Thomas Zimmermann <tzimmermann at suse.de> wrote:

> Am 08.09.23 um 12:58 schrieb Maxime Ripard:
> 
> > Hi,
> > 
> > On Fri, Sep 08, 2023 at 11:21:51AM +0200, Thomas Zimmermann wrote:
> > 
> > > Am 25.08.23 um 16:04 schrieb Jocelyn Falempe:
> > > [...]
> > > 
> > > > + *
> > > > + * But there are two exceptions only for dumb buffers:
> > > > + * * To support XRGB8888 if it's not supported by the hardware.
> > > 
> > > > + * * Any driver is free to modify its internal representation of the format,
> > > > + * as long as it doesn't alter the visible content in any way, and doesn't
> > > > + * modify the user-provided buffer. An example would be to drop the
> > > > + * padding component from a format to save some memory bandwidth.
> > > 
> > > I have strong objections to this point, especially as you're apparently
> > > trying to sneak this in after our discussion.
> > 
> > I think it's an unfair characterization. This was discussed on
> > #dri-devel, and went through several rounds over the mailing lists, with
> > you in Cc for each. How is that sneaking something in?
> 
> 
> A few months ago, we had a flamewar'ish IRC discussion on format
> conversion within the kernel. The general sentiment was that the kernel
> drivers should use what ever is provided by userspace without further
> processing. The short argument was 'userspace knows better'. The only
> exception is for supporting XRGB8888 on hardware that would otherwise
> not support it. After some consideration, I agree with all that. (Back
> then I didn't.)

(FWIW, as a userspace dev, the above makes perfect sense to me.)