I'd really like this for Mesa so we can pull drm_fourcc.h into common
WSI code. Why has it stalled?
--Jason
On Tue, Dec 8, 2020 at 2:33 AM James Park wrote:
>
> I updated the patch earlier today incorporating the suggestions. I also had
> to bring back "#include " to drm.h because there's some
I updated the patch earlier today incorporating the suggestions. I also had
to bring back "#include " to drm.h because there's some
sanity check that fails, as if it doesn't scan past the first level of
#includes..
- James
On Mon, Dec 7, 2020 at 3:14 AM Pekka Paalanen wrote:
> On Mon, 07 Dec 20
Oh, I thought you meant:
#include "drm_basic_types.h"
#include "drm_fourcc.h"
Yours should work too. I don't have a preference vs. what I already have,
so if no one says anything, I can switch over to yours.
Thanks,
James
On Mon, Dec 7, 2020 at 2:53 AM Simon Ser wrote:
> On Monday, December 7
Not to make too big a deal of it, but the idea was that if you went out of
your way to define DRM_FOURCC_STANDALONE in your code base, that you would
also go through the pain of removing drm.h includes elsewhere. It's too
annoying of an implication to document/communicate, so I'm happier with the
o
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
Thanks,
James
On Mon, Dec
That would work, but that's kind of an annoying requirement. I would prefer
the header to be self-sufficient.
Thanks,
James
On Mon, Dec 7, 2020 at 2:47 AM Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen <
> ppaala...@gmail.com> wrote:
>
> > But then, the code in the
On Mon, 07 Dec 2020 10:53:49 +
Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park
> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before
On Monday, December 7th, 2020 at 11:49 AM, James Park
wrote:
> That would work, but that's kind of an annoying requirement. I would
> prefer the header to be self-sufficient.
I don't want to make it more confusing than before, but here Pekka (I
think) suggests to replace this:
diff --git a/inc
On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen
wrote:
> But then, the code in the header should be literally
>
> #ifndef DRM_FOURCC_STANDALONE
> #include "drm.h"
> #endif
>
> without an #else branch.
As long as there is a #include "drm_basic_types.h" right before
(drm_fourcc.h needs
On Mon, 7 Dec 2020 12:35:14 +0200
Pekka Paalanen wrote:
> On Mon, 7 Dec 2020 01:08:58 -0800
> James Park 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 c
On Mon, 7 Dec 2020 01:08:58 -0800
James Park 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/0cc8ae7
On Monday, December 7th, 2020 at 11:00 AM, James Park
wrote:
> Not to make too big a deal of it, but the idea was that if you went
> out of your way to define DRM_FOURCC_STANDALONE in your code base,
> that you would also go through the pain of removing drm.h includes
> elsewhere. It's too annoy
On Monday, December 7th, 2020 at 9:57 AM, James Park
wrote:
> I could adjust the block to look like this:
>
> #ifdef DRM_FOURCC_STANDALONE
> #if defined(__linux__)
> #include
> #else
> #include
> typedef uint32_t __u32;
> typedef uint64_t __u64;
> #endif
> #else
> #include "drm.h"
> #endif
Th
I could adjust the block to look like this:
#ifdef DRM_FOURCC_STANDALONE
#if defined(__linux__)
#include
#else
#include
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_f
On Fri, 4 Dec 2020 11:07:41 -0800
James Park wrote:
> I could adjust the block to look like this:
>
> #ifdef DRM_FOURCC_STANDALONE
> #if defined(__linux__)
> #include
> #else
> #include
> typedef uint32_t __u32;
> typedef uint64_t __u64;
> #endif
> #else
> #include "drm.h"
> #endif
>
> Altern
On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen wrote:
>
> On Thu, 3 Dec 2020 21:45:14 +0100
> Daniel Vetter wrote:
>
> > On Thu, Dec 3, 2020 at 7:55 PM James Park
> > wrote:
> > >
> > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't
> > > intentional, right? Should I put all the integ
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?
Thanks,
James
On Thu, Dec 3, 2020 at 6:52 AM Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 9:18 AM Michel Dänzer wrote:
> >
> > On 2020
On Thu, 3 Dec 2020 21:45:14 +0100
Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 7:55 PM James Park 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 tha
On Thu, Dec 3, 2020 at 7:55 PM James Park 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
On Thu, Dec 3, 2020 at 9:18 AM Michel Dänzer wrote:
>
> On 2020-12-02 8:47 p.m., James Park wrote:
> >
> > 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 t
On Thursday, December 3, 2020 1:54 PM, Ville Syrjälä
wrote:
> > 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 b
On Wed, Dec 02, 2020 at 11:25:58PM +0100, Daniel Vetter wrote:
> On Wed, Dec 2, 2020 at 8:48 PM James Park wrote:
> >
> > I can avoid modifying drm.h by doing this to drm_fourcc.h:
> >
> > #ifdef _WIN32
> > #include
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > And
On Wed, 2 Dec 2020 23:25:58 +0100
Daniel Vetter wrote:
> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).
Hi,
FWIW, libweston core needs drm_fourcc.h too, even if nothing would ever
use DRM or need libdrm otherwise.
On 2020-12-02 8:47 p.m., James Park wrote:
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 Mesa src/amd/ code
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 doe
This will allow Mesa to port code to Windows more easily.
Hide BSD header and drm_handle_t behind _WIN32 check.
Change __volatile__ to volatile, which is standard.
Signed-off-by: James Park
---
include/uapi/drm/drm.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
I can avoid modifying drm.h by doing this to drm_fourcc.h:
#ifdef _WIN32
#include
typedef uint64_t __u64;
#else
#include "drm.h"
#endif
And this to amdgpu_drm.h:
#ifdef _WIN32
#include
typedef int32_t __s32;
typedef uint32_t __u32;
typedef uint64_t __u64;
#else
#include "drm.h"
#endif
But no
Attempting to submit patch in response to
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712454
This will allow Mesa to port code to Windows more easily.
Hide BSD header and drm_handle_t behind _WIN32 check.
Change __volatile__ to volatile, which is standard.
Signed-off-by
On Wed, Dec 2, 2020 at 8:48 PM James Park wrote:
>
> I can avoid modifying drm.h by doing this to drm_fourcc.h:
>
> #ifdef _WIN32
> #include
> typedef uint64_t __u64;
> #else
> #include "drm.h"
> #endif
>
> And this to amdgpu_drm.h:
>
> #ifdef _WIN32
> #include
> typedef int32_t __s32;
> typede
On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer 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
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer 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 whe
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.
--
Earthling Michel Dänzer
Can you add a Signed-off-by line to your commit message? This means
you agree to the Developer Certificate of Origin [1].
[1]: https://developercertificate.org/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
This will allow Mesa to port code to Windows more easily.
Hide BSD header and drm_handle_t behind _WIN32 check.
Change __volatile__ to volatile, which is standard.
---
include/uapi/drm/drm.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/uapi/drm/drm.h b/
34 matches
Mail list logo
