On 3 June 2015 at 18:16, Emil Velikov emil.l.velikov@gmail.com wrote:

Hi Mikko,

On 30 May 2015 at 16:38, Mikko Rapeli mikko.rapeli@iki.fi wrote:

...

Fixes compiler error:

drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory

Signed-off-by: Mikko Rapeli mikko.rapeli@iki.fi

include/uapi/drm/via_drm.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h index 8b0533c..791531e 100644 --- a/include/uapi/drm/via_drm.h +++ b/include/uapi/drm/via_drm.h @@ -24,6 +24,7 @@ #ifndef _VIA_DRM_H_ #define _VIA_DRM_H_

+#include <linux/types.h>

As mentioned elsewhere one could avoid this, and just use drm.h to manage the approapriate types (uint32_t vs __u32 and so on).

...

#include <drm/drm.h>

/* WARNING: These defines must be the same as what the Xserver uses. @@ -33,9 +34,6 @@ #ifndef _VIA_DEFINES_ #define _VIA_DEFINES_

-#ifndef __KERNEL__ -#include "via_drmclient.h" -#endif

I fear that this one is a particular example of a nasty legacy from the UMS days. The file is available/provided in very old mesa versions and at the very same time mesa requires via_drm.h. So I would kindly ask that you:

• Grab the libdrm userspace package, and apply a similar change.
• Rebuild/install the above.
• Fetch mesa 7.11, and try building the via dri module. Ideally

things will continue to build, alternatively we might need to add another/additional guard for this include.

So the situation is "funnier" than expected: - There are at least two users of via_drm.h (mesa and xf86-video-via) with each providing different via_drmclient.h. - Neither of the two projects includes the latter header, despite that it uses the macros defined within. - via_drm.h is included via multiple headers, so adding extra ifdef guards sounds like a bad idea. - While new version of the ddx can be released, a mesa one is unlikely - 7.11.2 was released ~4 years ago. - Even if we cover the above two project, other projects (how many, where are they hosted, etc.) may need the same treatment.

With the above said I'd suspect that we're safer leaving the include as is ? Yes, it is busted if one tries to use the standalone header, jet (most/all?) official users rely on that behaviour :-\

Cheers Emil