[PATCH] drm: Fix drm.h uapi header for Windows

[James Park]

I could adjust the block to look like this:

#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

Alternatively, I could create a new common header to be included from both
drm.h and drm_fourcc.h, drm_base_types.h or something like that:

#ifdef DRM_FOURCC_STANDALONE
#include "drm_base_types.h"
#else
#include "drm.h"
#endif

On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter <daniel at ffwll.ch> wrote:

> On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Thu, 3 Dec 2020 21:45:14 +0100
> > Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > > On Thu, Dec 3, 2020 at 7:55 PM James Park <james.park at lagfreegames.com>
> wrote:
> > > >
> > > > The trailing underscore for  DRM_FOURCC_STANDALONE_ isn't
> > > > intentional, right? Should I put all the integer types, or just the
> > > > ones that are used in that file?
> > >
> > > Yeah that trailing _ just slipped in. And I'd just do the types
> > > already used. I don't think anything else than __u32 (for drm fourcc)
> > > and __u64 (for drm modifier) is needed.
> >
> > Hi,
> >
> > can that create conflicts if userspace first includes drm_fourcc.h and
> > then drm.h?
> >
> > I would find it natural to userspace have generic headers including
> > drm_fourcc.h and then DRM-specific C-files including drm.h as well
> > (through libdrm headers). I think Weston might already do this.
> >
> > The generic userspace (weston) header would obviously #define
> > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as well.
>
> Hm yes that would break. I guess we could just include the linux types
> header for this. And I guess on windows you'd need to have that from
> somewhere. Or we just require that users of the standalone header pull
> the right header or defines in first?
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201204/d4d140a6/attachment-0001.htm>