[PATCH 0/9] uapi: drm: fixes for userspace compilation

[Emil Velikov]

On 13 November 2015 at 21:36, Gabriel Laskar <gabriel at lse.epita.fr> wrote:
> On Fri, 13 Nov 2015 20:38:51 +0000
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 13 November 2015 at 19:31, Gabriel Laskar <gabriel at lse.epita.fr> wrote:
>> > On Fri, 13 Nov 2015 20:24:30 +0100
>> > Gabriel Laskar <gabriel at lse.epita.fr> wrote:
>> >
>> > Sorry for the noise, I had just saw the first version.
>> >
>> Heh I was wondering what's happening. I guess I should have been more
>> helpful and given you a link, rather than just throwing you a name.
>> Sorry about that.
>
> No worries, I will check a little more next time.
>
>> From a very quick look I believe that the only part that is not
>> covered by Mikko is virtgpu_drm.h as it landed recently. Other than
>> that - with the explicit include of drm.h from the respective headers,
>> and the stdint to __foo type conversion things should actually work.
>
> I will resend that patch.
>
> There is still some issues on the headers, like the inclusion of drm.h.
>
> AFAIK, we should include "drm.h", in order to minimize the changes
> between linux/libdrm when importing, as the folders are not always the
> same (on Archlinux for example, drm.h is installed
> in /usr/include/libdrm/drm.h). This is not always the case in some of
> the headers:
>
I'm afraid we cannot do this. Things should just work without the
extra include directive (from your earlier example). We can easily fix
this and other issues in an automated way during import.

> * drm_sarea.h
> * exynos_drm.h
> * i810_drm.h
> * i915_drm.h
> * mga_drm.h
> * msm_drm.h
> * nouveau_drm.h
> * omap_drm.h
> * r128_drm.h
> * savage_drm.h
> * tegra_drm.h
> * via_drm.h
> * vmwgfx_drm.h (with #ifndef __KERNEL__ guards around it)
>
Imho we should drop the guard and keep the include.

> * there is still some headers that are including stddef.h for no
>   visible reasons (msm_drm.h and qxl_drm.h).
I'd assume those are added for size_t. Which interestingly enough
isn't used in either header. I'm leaning that we can nuke it.

> * drm_fourcc.h and drm_mode.h are still using linux/types.h
>
Did not see (even expect) those - good catch. The #include drm/drm.h
should suffice there imho.

> I can send patches for them too, I just need to know if this is useful,
> and not just nitpicking for you.
>
Everything but the s|drm/drm.h|drm.h| suggestion is pretty valid imho.

As a follow up we can even make the headers C++ friendly, but that
obviously is nothing for you to worry about :-)

Huge thanks for reviving this topic.
Emil