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

[Ville Syrjälä]

On Wed, Dec 02, 2020 at 11:25:58PM +0100, Daniel Vetter wrote:
> On Wed, Dec 2, 2020 at 8:48 PM James Park <james.park at lagfreegames.com> wrote:
> >
> > I can avoid modifying drm.h by doing this to drm_fourcc.h:
> >
> > #ifdef _WIN32
> > #include <stdint.h>
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > And this to amdgpu_drm.h:
> >
> > #ifdef _WIN32
> > #include <stdint.h>
> > typedef int32_t  __s32;
> > typedef uint32_t __u32;
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > But now I'm touching two files under drm-uapi instead of one, and weirdly.
> >
> > If we're trying to cut ties with the drm-uapi folder entirely, the stuff ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these definitions?
> 
> The drm_fourcc.h maybe makes some sense (I think in some places mesa
> uses these internally, and many drivers use the modifiers directly in
> the main driver). But the amdgpu header should be all ioctl stuff,
> which should be all entirely in the winsys only.
> 
> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).

Isn't the only thing it needs the __u32? I would think we could just
replace those with unsigned int (DRM_FORMAT_BIG_ENDIAN already assumes
int is 32bit it seems) and drop the drm.h.

Or are we're worried something already depends on getting drm.h via
just including drm_fourcc.h?

-- 
Ville Syrjälä
Intel