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

[Pekka Paalanen]

On Mon, 7 Dec 2020 01:08:58 -0800
James Park <james.park at lagfreegames.com> wrote:

> I'm not completely sure what you're saying, but doesn't drm_base_types.h
> (now drm_basic_types.h) make things robust to header order? The patch is in
> another email. You can also see it here:
> https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18

If that is robust (I don't know if it is, I haven't checked), then why
do you have #ifdef DRM_FOURCC_STANDALONE in it at all?

Like Simon said:

On Mon, 07 Dec 2020 10:02:36 +0000
Simon Ser <contact at emersion.fr> wrote:

> In my compositors I'd like to globally define DRM_FOURCC_STANDALONE
> (to make sure I don't miss any #define) but I still may include drm.h
> in the same files as well.

If any project #defines it globally, then what good does checking for
it do? Why not assume that everyone will always want what
DRM_FOURCC_STANDALONE would bring?


Thanks,
pq

> 
> Thanks,
> James
> 
> On Mon, Dec 7, 2020 at 12:51 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Fri, 4 Dec 2020 11:07:41 -0800
> > James Park <james.park at lagfreegames.com> wrote:
> >  
> > > I could adjust the block to look like this:
> > >
> > > #ifdef DRM_FOURCC_STANDALONE
> > > #if defined(__linux__)
> > > #include <linux/types.h>
> > > #else
> > > #include <stdint.h>
> > > typedef uint32_t __u32;
> > > typedef uint64_t __u64;
> > > #endif
> > > #else
> > > #include "drm.h"
> > > #endif
> > >
> > > Alternatively, I could create a new common header to be included from  
> > both  
> > > drm.h and drm_fourcc.h, drm_base_types.h or something like that:
> > >
> > > #ifdef DRM_FOURCC_STANDALONE
> > > #include "drm_base_types.h"
> > > #else
> > > #include "drm.h"
> > > #endif  
> >
> > Hi,
> >
> > my point is, any solution relying on DRM_FOURCC_STANDALONE will fail
> > sometimes, because there is no reason why userspace would *not* #define
> > DRM_FOURCC_STANDALONE. Hence, #ifdef DRM_FOURCC_STANDALONE is
> > completely moot, you have to make the headers work in any include
> > order when DRM_FOURCC_STANDALONE is defined anyway.
> >
> >
> > Thanks.
> > pq
> >  
> > > On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> > >  
> > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen <ppaalanen at gmail.com>  
> > wrote:  
> > > > >
> > > > > On Thu, 3 Dec 2020 21:45:14 +0100
> > > > > Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > >  
> > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park <  
> > james.park at lagfreegames.com>  
> > > > wrote:  
> > > > > > >
> > > > > > > The trailing underscore for  DRM_FOURCC_STANDALONE_ isn't
> > > > > > > intentional, right? Should I put all the integer types, or just  
> > the  
> > > > > > > ones that are used in that file?  
> > > > > >
> > > > > > Yeah that trailing _ just slipped in. And I'd just do the types
> > > > > > already used. I don't think anything else than __u32 (for drm  
> > fourcc)  
> > > > > > and __u64 (for drm modifier) is needed.  
> > > > >
> > > > > Hi,
> > > > >
> > > > > can that create conflicts if userspace first includes drm_fourcc.h  
> > and  
> > > > > then drm.h?
> > > > >
> > > > > I would find it natural to userspace have generic headers including
> > > > > drm_fourcc.h and then DRM-specific C-files including drm.h as well
> > > > > (through libdrm headers). I think Weston might already do this.
> > > > >
> > > > > The generic userspace (weston) header would obviously #define
> > > > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as  
> > well.  
> > > >
> > > > Hm yes that would break. I guess we could just include the linux types
> > > > header for this. And I guess on windows you'd need to have that from
> > > > somewhere. Or we just require that users of the standalone header pull
> > > > the right header or defines in first?
> > > > -Daniel
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> > > >  
> >
> >  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201207/5c87f45a/attachment.sig>