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

[Thomas Zimmermann]

Hi Maxime

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.)

A few weeks ago I received a patch to do an implicit conversion from 
XRGB8888 to RGB888 within mgag200. [1] I don't have a link to the 
discussion, but I NAK'ed that patch pretty hard on IRC by following that 
other discussion.

And know I find that this patch (even in its v1) contains language that 
retroactively legitimizes the mgag200 patch. I wrote 'apparently' I my 
reply, as I assume that there's more to it, but how does it not look 
like an attempt to sneak in something that is known to be controversial?

It might have been better to discuss the question separately on the 
dri-devel ML. Maybe we can do this here.

Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/531879/?series=116381&rev=1

> 
>> NAK on this part from my side.
>>
>> If you want userspace to be able to use a certain format, then export the
>> corresponding 4cc code. Then let userspace decide what to do about it. If
>> userspace pick a certain format, go with it.
>>
>> Hence, no implicit conversion from XRGB888 to RGB888, just because it's
>> possible.
> 
> I'm not sure what's your argument is, really. Last time we discussed
> this, you were saying that you were enforcing that rule because that was
> the outcome of that (painful) discussion with Pekka and Javier. It turns
> out that both Pekka and Javier are ok with the patch, so it's not clear
> to me what your objections are at this point.
> 
> Are you really arguing that we shouldn't allow a driver to consume less
> resources while not affecting any other component in the system in any
> way?
> 
> Maxime

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230908/2791ecf8/attachment.sig>