On Mon, 7 Dec 2020 01:08:58 -0800 James Park <james.park@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxx> wrote: > > > On Fri, 4 Dec 2020 11:07:41 -0800 > > James Park <james.park@xxxxxxxxxxxxxxxx> 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@xxxxxxxx> wrote: > > > > > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> > > wrote: > > > > > > > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > > > > Daniel Vetter <daniel@xxxxxxxx> wrote: > > > > > > > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park < > > james.park@xxxxxxxxxxxxxxxx> > > > > 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 > > > > > > > >
Attachment:
pgpQuxWZYbpyx.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
