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@xxxxxxxxxx>
> ---
> 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
> + * 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.
> + * 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.
Otherwise, on principle, I'm fine with that change :)
Maxime
Attachment:
signature.asc
Description: PGP signature
