[PATCH] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard

James Park james.park at lagfreegames.com
Tue Feb 2 23:24:51 UTC 2021


On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> At the same time drm.h pulls a lot of unneeded symbols.
>
> Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> declaration of said symbols.
>
> When used on linux - this is a trivial but only when building in strict c99
> mode. One is welcome to ignore the warning, silence it or use c11. If neither
> of the three is an option, then do _not_  set the new guard.
>
> Cc: James Park <james.park at lagfreegames.com>
> Cc: Pekka Paalanen <pekka.paalanen at collabora.com>
> Cc: Simon Ser <contact at emersion.fr>
> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
> ---
> As mentioned before - there's little point in having yet another header
> since keeping those in sync has been a PITA in the past.
> ---
>  include/uapi/drm/drm_fourcc.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 6f0628eb13a6..c1522902f6c9 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,26 @@
>  #ifndef DRM_FOURCC_H
>  #define DRM_FOURCC_H
>
> +/*
> + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not want
> + * to pull drm.h into your application.
> + */
> +#ifdef DRM_FOURCC_STANDALONE
> +#if defined(__linux__)
> +
> +#include <linux/types.h>
> +
> +#else /* One of the BSDs */
> +
> +#include <stdint.h>
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +
> +#endif /* __linux __ */
> +
> +#else
>  #include "drm.h"
> +#endif /* DRM_FOURCC_STANDALONE */
>
>  #if defined(__cplusplus)
>  extern "C" {
> --
> 2.30.0
>

One of my earlier solutions similarly would have forced people to deal
with duplicate typedefs, and we arrived at the current solution
because we didn't want to burden anyone with that. I feel like having
the extra include-guarded file is the lesser of evils. If it helps the
patch go through, then I'd drop my preference but I really think the
current solution is better.

- James


More information about the dri-devel mailing list