On Friday, September 8th, 2023 at 22:22, Thomas Zimmermann <tzimmermann@xxxxxxx> 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.)
