On Mon, 7 Dec 2020 01:08:58 -0800 James Park james.park@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/0cc8ae750bfd9eab7e31c7de6aa84f24682f...
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@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@gmail.com wrote:
On Fri, 4 Dec 2020 11:07:41 -0800 James Park james.park@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@ffwll.ch wrote:
On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen ppaalanen@gmail.com
wrote:
On Thu, 3 Dec 2020 21:45:14 +0100 Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Dec 3, 2020 at 7:55 PM James Park <
james.park@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