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

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1807 bytes --]

Hi

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

Best regards
Thomas


> + *     On most hardware, VRAM read access are slow, so when doing the software
> + *     conversion, the dumb buffer should be allocated in system RAM in order to
> + *     have decent performance.
> + *     Extra care should be taken when doing software conversion with
> + *     DRM_CAP_DUMB_PREFER_SHADOW, there are more detailed explanations here:
> + *     https://lore.kernel.org/dri-devel/20230818162415.2185f8e3@eldfell/
>    */
>   
>   static unsigned int drm_num_planes(struct drm_device *dev)
> 
> base-commit: 82d750e9d2f5d0594c8f7057ce59127e701af781

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]