[PATCH 1/1] drm/fourcc: Add documentation about software color conversion.

[Jocelyn Falempe]

On 10/08/2023 09:45, Maxime Ripard wrote:
> Hi
> 
> On Mon, Aug 07, 2023 at 03:45:15PM +0200, Jocelyn Falempe wrote:
>> After discussions on IRC, the consensus is that the DRM drivers should
>> not do software color conversion, and only advertise the supported formats.
>> Update the doc accordingly so that the rule and exceptions are clear for
>> everyone.
>>
>> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com>
>> ---
>>   include/uapi/drm/drm_fourcc.h | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 8db7fd3f743e..00a29152da9f 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -38,6 +38,13 @@ extern "C" {
>>    * fourcc code, a Format Modifier may optionally be provided, in order to
>>    * further describe the buffer's format - for example tiling or compression.
>>    *
>> + * DRM drivers should not do software color conversion, and only advertise the
>> + * format they support in hardware. But there are two exceptions:
> 
> I would do a bullet list here:
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#lists-and-quote-like-blocks
> 
ok, that would look better.

>> + * The first is to support XRGB8888 if the hardware doesn't support it, because
>> + * it's the de facto standard for userspace applications.
> 
> We can also provide a bit more context here, something like:
> 
> All drivers must support XRGB8888, even if the hardware cannot support
> it. This has become the de-facto standard and a lot of user-space assume
> it will be present.

ok, I can add this before the first paragraph.
> 
>> + * The second is to drop the unused bits when sending the data to the hardware,
>> + * to improve the bandwidth, like dropping the "X" in XRGB8888.
> 
> I think it can be made a bit more generic, with something like:
> 
> 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. An example
> would be to drop the padding component from a format to save some memory
> bandwidth.

ok,

> 
> Otherwise, on principle, I'm fine with that change :)

Thanks, I will wait a bit for other comments, and send a v2.

> 
> Maxime