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@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?