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:
OpenPGP_signature
Description: OpenPGP digital signature
