<div dir="ltr">I can avoid modifying drm.h by doing this to drm_fourcc.h:<div><br></div><div>#ifdef _WIN32<br>#include <stdint.h><br>typedef uint64_t __u64;<br>#else<br>#include "drm.h"<br>#endif<br></div><div><br></div><div>And this to amdgpu_drm.h:</div><div><br></div><div>#ifdef _WIN32<br>#include <stdint.h><br>typedef int32_t  __s32;<br>typedef uint32_t __u32;<br>typedef uint64_t __u64;<br>#else<br>#include "drm.h"<br>#endif<br></div><div><br></div><div>But now I'm touching two files under drm-uapi instead of one, and weirdly.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-12-02 1:46 p.m., Daniel Vetter wrote:<br>
> On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br>
>><br>
>> On 2020-12-01 11:01 a.m., James Park wrote:<br>
>>> This will allow Mesa to port code to Windows more easily.<br>
>><br>
>> As discussed in<br>
>> <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779</a><br>
>> , including drm.h makes no sense when building for Windows.<br>
> <br>
> Yeah I think it'd be cleanest if we can avoid this. If not I think the<br>
> right fix would be to split out the actually needed parts from drm.h<br>
> into a new header (still included by drm.h for backwards compat<br>
> reasons) which mesa can use. Since it looks like the problematic parts<br>
> are the legacy gunk, and not the new ioctl structures. Pulling out<br>
> drm_render.h for all the render stuff and mabe drm_vblank.h for the<br>
> vblank stuff (which would fit better in drm_mode.h but mistakes were<br>
> made, oops).<br>
<br>
If anything currently in drm.h is needed while building for Windows, it <br>
points to a broken abstraction somewhere in userspace. (Specifically, <br>
the Mesa Gallium/Vulkan winsys is supposed to abstract away platform <br>
details like these)<br>
<br>
<br>
-- <br>
Earthling Michel Dänzer               |               <a href="https://redhat.com" rel="noreferrer" target="_blank">https://redhat.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</blockquote></div>