A similar problem exists with gallium:

gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/egl/main -I../../../../src/egl/wayland/wayland-drm/ -I../../../../include -I../../../../src/gallium/winsys -I/usr/include/libdrm   -I../../../../src/gbm/main -I../../../../src/gallium/state_trackers/gbm -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_XCB_DRI2 -g -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_XCB_DRI2 -fvisibility=hidden drm/native_drm.c -o drm/native_drm.o
In file included from ../../../../src/gallium/state_trackers/gbm/gbm_gallium_drmint.h:35,
                 from drm/native_drm.c:36:
../../../../src/gbm/main/common.h:31:21: error: libudev.h: No such file or directory
In file included from ../../../../src/gallium/state_trackers/gbm/gbm_gallium_drmint.h:35,
                 from drm/native_drm.c:36:
../../../../src/gbm/main/common.h:34: warning: ‘struct udev’ declared inside parameter list
../../../../src/gbm/main/common.h:34: warning: its scope is only this definition or declaration, which is probably not what you want
make: *** [drm/native_drm.o] Error 1


IMO, if gbm is not enabled, The egl drm platform  should build anyway.

Thanks, the egl_dri2 compilation failure should be fixed by b2d6375e6a64ac12f35f8a611ebf2016e4a6dd42.

The egl_gallium failure one looks like being manually involved?
The drm egl platform shouldnt be build if gbm is disabled.

We cant really build the drm platform without gbm,
since gbm is the new native egl platform for drm.
I fixed a typo, so that configure reflects that (9b8cd499303d9bcb60f40ef14553cb38cea6a897).

The second build was configured using
--with-egl-platforms=drm and --disable-gdm.

Could you describe a bit more in detail why we can't build the drm platform without gdm? What exactly are gdm strictly needed for?

I was under the impression that gdm was only strictly required for certain EGL extensions or Wayland?

In general, when it comes to EGL I think it's very important that we maintain the possibility of a very lean build, so that embedded platforms that will never use a certain feature can skip it from the build.

Why, should we, for example, need to install libudev development files for embedded systems that don't use udev?

I suggest keeping the gdm parts of the egl drm data structures conditioned on gdm being enabled.

Thanks,
Thomas

(In reply to comment #3)
> The second build was configured using
> --with-egl-platforms=drm and --disable-gdm.
> 

Oh, should be s/gdm/gbm/ of course.

/Thomas

(In reply to comment #3)
> The second build was configured using
> --with-egl-platforms=drm and --disable-gdm.
> 
> Could you describe a bit more in detail why we can't build the drm platform
> without gdm? What exactly are gdm strictly needed for?
> 

Well, as mentioned, gbm is the native egl display type for the drm platform backend (maybe drm platform should be renamed to gbm someday).
e.g:
   fd = open("/dev/dri/card0", O_RDWR);
   gbm = gbm_create_device(fd);
   edpy = eglGetDisplay(gbm);

> I was under the impression that gdm was only strictly required for certain EGL
> extensions or Wayland?

gbm is intended to replace the EGL_MESA_drm_image extension which was needed to run egl on DRM/KMS while having control over KMS (in contrast to EGL_MESA_screen_surface which abstracts KMS).

gbm is not needed for wayland (nor the wayland stuff inside mesa), its just that wayland compositors will likely use it to create buffers for use with KMS/OpenWF Display.

> In general, when it comes to EGL I think it's very important that we maintain
> the possibility of a very lean build, so that embedded platforms that will
> never use a certain feature can skip it from the build.

libudev is needed for drm anyway, to figure out which driver to use (This is since commita433755ec5c48088a0d8a340851a1a8be9e58897).

> Why, should we, for example, need to install libudev development files for
> embedded systems that don't use udev?

Do these embedded systems really need the drm platform, or dont they want the fbev platform?

> 
> I suggest keeping the gdm parts of the egl drm data structures conditioned on
> gdm being enabled.
> 
> Thanks,
> Thomas

After doing a bit of readup on this and looking at the commits, I guess you're probably right on all accounts,

but I agree, we should probably rename the platform gdm.

An embedded device needing something leaner or want to give a device name as an environment variable should probably create its own EGL platform code.

However, that unfortunate configure option combination should probably be fixed so that we see a configure error instead of a compilation error. 

Thomas

(In reply to comment #6)
> After doing a bit of readup on this and looking at the commits, I guess you're
> probably right on all accounts,
> 
> but I agree, we should probably rename the platform gdm.
> 
> An embedded device needing something leaner or want to give a device name as an
> environment variable should probably create its own EGL platform code.

I don't think it gets much leaner that gbm.  The gbm code is basically the driver mapping and loading code we had in the drm platform, refactored into an actual native EGL platform.  We moved the code around so we load the driver early (ie before eglGetDisplay), which lets us allocate native buffers for creating egl surfaces/images, instead of relying on an awkward extension [1].

I don't think udev is a problematic requirement for embedded devices (I think it's hard to build one without), but one way you could go leaner is to drop the PCI ID -> driver maps and the libudev dependency, and instead provide a custom mechanism to map from fd to driver name.  I don't think that conflicts with gbm though, it could be a configure option if we wanted to do that, but as Benjamin said, nothing has changed in terms of dependencies or overhead from how the drm platform worked.
 
> However, that unfortunate configure option combination should probably be fixed
> so that we see a configure error instead of a compilation error. 

Yes, definitely.

[1] Awkward because it's not in line with how EGLImage was designed.  EGLImage are always supposed to be created for existing buffers such as textures, render buffers or native pixmaps.  EGL_MESA_drm_image creates an EGLImage out of nothing which doesn't work well with the EGLImage specification language.  By introducing a native platform that just lets us create a native pixmap, we're more aligned with how EGL platforms are supposed to work and can rely on EGL_KHR_image_pixmap for creating EGLImages suitable for scanout.

(In reply to comment #7)
[snip]
> I don't think udev is a problematic requirement for embedded devices (I think
> it's hard to build one without), but one way you could go leaner is to drop the
> PCI ID -> driver maps and the libudev dependency, and instead provide a custom
> mechanism to map from fd to driver name.  I don't think that conflicts with gbm
> though, it could be a configure option if we wanted to do that, but as Benjamin
> said, nothing has changed in terms of dependencies or overhead from how the drm
> platform worked.
Both i915 and radeon kernel modules provides GETPARAM to get the PCI id.  Combined with drmGetVersion, couldn't it be used as a reliable mean for PCI id when libudev is not available?

First, I have nothing at all against GBM, it probably serves its purpose well.

I'm curious, however, to why exactly it is needed for the gallium drm egl platform code. Correct me if I'm wrong, but it looks to be like the gallium egl drm code now just uses GBM to call into the gallium GBM state tracker which, in turn calls the gallium code directly. Something that could well be done from the gallium drm egl code directly? In addition, the egl state tracker drm platform code needs to access structures internal to the gallium GBM state tracker?

Two additional layers of abstraction, that, in addition pulls in a strong requirement for udev, but as I understand it, it seems to be the loader code that has this requirement.

And for the pipe driver loader code, it could be useful for other things than GBM. There are other state trackers that optionally would want to use it (for example XA). without needing to use the other parts of GBM.

So I think the optimal way to do this is
 
1) to break out the pipe driver loader, and make it optionally available to any state tracker.
2) When that's done, (correct me if I'm wrong), there wouldn't be a need for the egl state tracker drm platform code to take the GBM roundtrips, and perhaps even to be optionally hard built against a specific gallium driver and drm device name?

> I don't think udev is a problematic requirement for embedded devices (I think
> it's hard to build one without), ...

I respectfully disagree.

The recent Linux kernel devtmpfs filesystem makes it easy to build an embedded device without udev.

After replacing udev with devtmpfs, my HP iPAQ hx4700 still happily boots Linux and starts a full X server (Xorg) with window manager (PAWM). The only noticeable difference is that it boots faster!

And those embedded devices which can employ static device nodes - because their hardware never changes - can avoid dynamic device node implementations (devfs, udev, devtmpfs) altogether.

I'm pretty sure that the original compilation failure is resolved now, yet feel free to reopen.

Whereas for anyone that is not a fan of libudev, we have the equivalent information retrieved by sysfs, and even via libdrm. If there is further interest, which one should be build when let's discuss this in a separate thread/bugreport.