I'm not sure what your suggestion is. Move which #ifdef block where?
I don't think everyone is of the opinion that adding drm.h and pulling in unnecessary kernel structures is fine. If I'm not mistaken, the reason people are making me jump through hoops in the first place is to avoid that.
I appreciate the feedback though.
- James
On Tue, Feb 2, 2021 at 9:28 AM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
Hi James,
On Tue, 2 Feb 2021 at 08:27, James Park <james.park@xxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> Is there something I can do to help move this patch along?
>
> Thanks,
> James Park
>
> On Thu, Dec 10, 2020 at 1:13 AM James Park <jpark37@xxxxxxxxxxxxxxxx> wrote:
>>
>> Create drm_basic_types.h to define types previously defined by drm.h.
>>
>> Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
>>
>> This will allow Mesa to port code to Windows more easily.
>>
>> Signed-off-by: James Park <jpark37@xxxxxxxxxxxxxxxx>
>> Acked-by: Simon Ser <contact@xxxxxxxxxxx>
>> Reviewed-by: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx>
>> ---
>> include/uapi/drm/drm.h | 12 ++-------
>> include/uapi/drm/drm_basic_types.h | 52 ++++++++++++++++++++++++++++++++++++++
>> include/uapi/drm/drm_fourcc.h | 4 +++
>> 3 files changed, 58 insertions(+), 10 deletions(-)
>> create mode 100644 include/uapi/drm/drm_basic_types.h
>>
Have you considered the possibility of having the ifdef block inlined
within drm_fourcc.h?
Sure some users might need to add an drm.h include in their code. At
the same time they also need to explicitly define
DRM_FOURCC_STANDALONE, so that is fine.
We had all sorts of issues with these headers in the past, so adding
another one might end up repeating some of those yet again.
Thanks
Emil
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
