[PATCH] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard

[James Park]

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 file is
problematic. I would prefer to keep the definitions deduplicated and
make the code robust even for edge cases unless there's a good reason
not to. Avoiding an extra file doesn't seem like a good enough reason
to me, but I also don't have to maintain codebases that rely on these
headers, so maybe there's something I'm overlooking.

Thanks,
James

On Wed, Feb 3, 2021 at 6:21 AM Simon Ser <contact at emersion.fr> wrote:
>
> On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov <emil.l.velikov at gmail.com> 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 because of
> some third-party header.
>
> Can you explain what were the past issues with introducing a new
> header?