Hi Kristian, Eric, Dave & others,

I'm wondering if anyone here would be kind enough to help me with this problem i'm having getting wayland to run.

I've got a gem & modesetting 2.6.28.rc5 kernel, and eagle & wayland are compiled ok.

But when running wayland, the DRM_IOCTL_GEM_FLINK call fails in eagle's intel.c:nativeInitDRICopyBuffer() function.

I've put some debugging prints into the drm section in my kernel. I found the drm_ioctl_gem_flink call is returning -EBADF because the handle it gets passed is, i guess, wrong. It looks suspicious to me, being so low:
When I run wayland, that handle is 5.
When I run eagle's "test", that handle is 3.
(But I don't know what it should be or what looks valid.)
Either way, that drm_ioctl_gem_flink function doesn't like it, because it tries to do the GEM object lookup with it (via the idr system), and doesn't find it. 

Before calling that ioctl, eagle gets that handle from the drmModeGetFB( ) function.

So does it look like (to you) that that drmModeGetFB( ) function is giving out a bogus handle?

Also can you tell me (Kristian) why that handle should be able to be found via idr lookup, should it have been created by something already, i.e. in the drmModeGetFB( ) function or somewhere?

Any help or pointers would be appreciated,
Thanks,
Tom.

----
p.s. Here's the part of the code in eagle/intel.c that I'm talking about:

fb = drmModeGetFB(display->fd, crtc->buffer_id);
if (fb == NULL) {
fprintf(stderr, "drmModeGetFB returns NULL\n");
return;
}
flink.handle = fb->handle;
if (ioctl(display->fd, DRM_IOCTL_GEM_FLINK, &flink) < 0) {    <<-- **********FAILS**********
fprintf(stderr, "failed to create buffer\n");     
return;
}
---
(another weird thing is that this code says that the ioctl is returning -1, but the kernel says the ioctl is returning -9. Oh well, I believe the kernel.)