[PATCH] drm: Allow drm_fourcc.h without including drm.h

[James Park]

I suppose I should do this to avoid fighting with <linux/types.h>

#ifdef DRM_FOURCC_STANDALONE
#if defined(__linux__)
#include <linux/types.h>
#else
#include <stdint.h>
typedef uint32_t __u32;
typedef uint64_t __u64;
#endif
#else
#include "drm.h"
#endif

I'll wait for more feedback before updating the patch though.

On Fri, Dec 4, 2020 at 1:47 AM James Park <james.park at lagfreegames.com>
wrote:

> The typedefs might also conflict on Linux if DRM_FOURCC_STANDALONE is
> enabled with whatever LInux declared __u32/__u64 as, but I think the
> implication is that once DRM_FOURCC_STANDALONE has been declared, that's
> kind of a promise not to include drm.h.
>
> I'm fine with this, but I'm not married to it if someone has a problem
> where they want to define DRM_FOURCC_STANDALONE, but also can't avoid
> including drm.h for some reason.
>
> On Fri, Dec 4, 2020 at 12:53 AM Simon Ser <contact at emersion.fr> wrote:
>
>> On Friday, December 4, 2020 5:53 AM, James Park <jpark37 at lagfreegames.com>
>> wrote:
>>
>> > +#ifdef DRM_FOURCC_STANDALONE
>> > +#include <stdint.h>
>> >
>> > +typedef uint32_t __u32;
>> > +typedef uint64_t __u64;
>> > +#else
>> > #include "drm.h"
>> > +#endif
>>
>> C11 allows duplicate typedefs, but older versions of the standard
>> don't AFAIK. If this is a concern, a solution would be to guard the
>> typedefs.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201204/8d75e1c2/attachment-0001.htm>