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

James Park james.park at lagfreegames.com
Thu Dec 3 01:24:10 UTC 2020


If the definitions in drm_fourcc.h make sense to live there, and we can't
remove drm.h from that header for backward compatibility, and the code that
I'm trying to compile on Windows needs the definitions in drm_fourcc.h,
then doesn't it make sense to adjust drm.h?

The patch that I'm proposing doesn't change very much. It might be easier
to read here:
https://github.com/jpark37/linux/commit/648e9281824ddc943c3ea6b34d6d6c154717a0a3

Thanks,
James

On Wed, Dec 2, 2020 at 2:26 PM Daniel Vetter <daniel at ffwll.ch> 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).
> -Daniel
>
> > Thanks,
> > James
> >
> > On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer <michel at daenzer.net>
> wrote:
> >>
> >> On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
> >> > On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer <michel at daenzer.net>
> wrote:
> >> >>
> >> >> On 2020-12-01 11:01 a.m., James Park wrote:
> >> >>> This will allow Mesa to port code to Windows more easily.
> >> >>
> >> >> As discussed in
> >> >>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
> >> >> , including drm.h makes no sense when building for Windows.
> >> >
> >> > Yeah I think it'd be cleanest if we can avoid this. If not I think the
> >> > right fix would be to split out the actually needed parts from drm.h
> >> > into a new header (still included by drm.h for backwards compat
> >> > reasons) which mesa can use. Since it looks like the problematic parts
> >> > are the legacy gunk, and not the new ioctl structures. Pulling out
> >> > drm_render.h for all the render stuff and mabe drm_vblank.h for the
> >> > vblank stuff (which would fit better in drm_mode.h but mistakes were
> >> > made, oops).
> >>
> >> If anything currently in drm.h is needed while building for Windows, it
> >> points to a broken abstraction somewhere in userspace. (Specifically,
> >> the Mesa Gallium/Vulkan winsys is supposed to abstract away platform
> >> details like these)
> >>
> >>
> >> --
> >> Earthling Michel Dänzer               |
> https://redhat.com
> >> Libre software enthusiast             |             Mesa and X developer
>
>
>
> --
> 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/20201202/4799b0ea/attachment-0001.htm>


More information about the dri-devel mailing list