On Wed, 3 Feb 2021 at 14:21, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
> wrote:
>
> > As said before, there are multiple ways to handle this without
> > introducing yet another UAPI header. I don't see why you're dismissing
> > all of them, can you elaborate?
On Wed, Feb 3, 2021 at 8:24 PM James Park wrote:
>
> Apologies for anything I've said so far that has been harsh. I'd like
> this discussion to be civil.
>
> I'm not sure if Simon is still on board with a patch given his thumbs
> up to Erik's comment on the Mesa merge request (which I responded to
Apologies for anything I've said so far that has been harsh. I'd like
this discussion to be civil.
I'm not sure if Simon is still on board with a patch given his thumbs
up to Erik's comment on the Mesa merge request (which I responded to),
but I would also like to know why adding another header fi
On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
wrote:
> As said before, there are multiple ways to handle this without
> introducing yet another UAPI header. I don't see why you're dismissing
> all of them, can you elaborate?
Because I hate it when I have to adjust my compiler flags
On Wed, 3 Feb 2021 at 13:47, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
> wrote:
>
> > No issue then, great. Let's merge this trivial solution and move on to
> > other things.
>
> Just because one compositor isn't affected isn't an excuse for the
> kernel to
On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
wrote:
> No issue then, great. Let's merge this trivial solution and move on to
> other things.
Just because one compositor isn't affected isn't an excuse for the
kernel to force its users to use a specific C standard.
_
On Wed, 3 Feb 2021 at 10:15, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 11:08 AM, Emil Velikov
> wrote:
>
> > On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
> > >
> > > On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> > > emil.l.veli...@gmail.com wrote:
> > >
> > > > As
On Wednesday, February 3rd, 2021 at 11:08 AM, Emil Velikov
wrote:
> On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
> >
> > On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> > emil.l.veli...@gmail.com wrote:
> >
> > > As summed in the commit message the burden is only applicable when a
On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> emil.l.veli...@gmail.com wrote:
>
> > As summed in the commit message the burden is only applicable when all
> > of the following are set:
> > - non-linux
> > - force DRM_FOURCC_STANDAL
On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
> As summed in the commit message the burden is only applicable when all
> of the following are set:
> - non-linux
> - force DRM_FOURCC_STANDALONE
> - c99 -pedantic
Oh, and FWIW, this is not a theoretica
On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
wrote:
> As summed in the commit message the burden is only applicable when all
> of the following are set:
> - non-linux
> - force DRM_FOURCC_STANDALONE
> - c99 -pedantic
>
> Even then, we're talking about a compilation warning. So ye
On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov wrote:
>
> Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> At the same time drm.h pulls a lot of unneeded symbols.
>
> Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> declaration of said symbols.
>
> When u
On Tue, Feb 2, 2021 at 4:57 PM Emil Velikov
wrote:
> On Tue, 2 Feb 2021 at 23:25, James Park
> wrote:
> >
> > On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov
> wrote:
> > >
> > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and
> __u64.
> > > At the same time drm.h pulls a lot of u
On Tue, 2 Feb 2021 at 23:25, James Park wrote:
>
> On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov wrote:
> >
> > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > At the same time drm.h pulls a lot of unneeded symbols.
> >
> > Add new guard DRM_FOURCC_STANDALONE, which whe
Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
At the same time drm.h pulls a lot of unneeded symbols.
Add new guard DRM_FOURCC_STANDALONE, which when set will use local
declaration of said symbols.
When used on linux - this is a trivial but only when building in strict
15 matches
Mail list logo
