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@xxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
