Wayland/Eagle compiled but not running

--===============5907930561293393695==
Content-Type: multipart/alternative; 
	boundary="----=_Part_2861_5373172.1227592301727"

------=_Part_2861_5373172.1227592301727
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.)

------=_Part_2861_5373172.1227592301727
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Kristian, Eric, Dave &amp; others,<div><br></div><div>I&#39;m wondering if anyone here would be kind enough to help me with this problem i&#39;m having getting wayland to run.</div><div><br></div><div>I&#39;ve got a gem &amp; modesetting 2.6.28.rc5 kernel, and eagle &amp; wayland are compiled ok.</div>
<div><br></div><div>But when running wayland, the DRM_IOCTL_GEM_FLINK call fails in eagle&#39;s intel.c:nativeInitDRICopyBuffer() function.</div><div><br></div><div>I&#39;ve put some debugging prints into the drm section in my kernel.&nbsp;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:</div>
<div>When I run wayland, that handle is 5.</div><div>When I run eagle&#39;s &quot;test&quot;, that handle is 3.</div><div>(But I don&#39;t know what it should be or what looks valid.)</div><div>Either way, that drm_ioctl_gem_flink function doesn&#39;t like it, because it tries to do the GEM object lookup with it (via the idr system), and doesn&#39;t find it.&nbsp;</div>
<div><br></div><div>Before calling that ioctl, eagle gets that handle from the drmModeGetFB( ) function.</div><div><br></div><div>So does it look like (to you) that that&nbsp;drmModeGetFB( )&nbsp;function is giving out a bogus handle?</div>
<div><br></div><div>Also can you tell me (Kristian) why that handle&nbsp;should&nbsp;be able to be found via idr lookup, should it have been created by something already, i.e. in the drmModeGetFB( ) function or somewhere?</div><div>
<br></div><div><div>Any help or pointers would be appreciated,</div><div>Thanks,<br></div><div>Tom.</div></div><div><br></div><div>----</div><div>p.s. Here&#39;s the part of the code in eagle/intel.c that I&#39;m talking about:</div>
<div><div><span class="Apple-tab-span" style="white-space:pre">	</span><br></div><div><span class="Apple-tab-span" style="white-space:pre">		</span>fb = drmModeGetFB(display-&gt;fd, crtc-&gt;buffer_id);</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>if (fb == NULL) {</div>
<div><span class="Apple-tab-span" style="white-space:pre">			</span>fprintf(stderr, &quot;drmModeGetFB returns NULL\n&quot;);</div><div><span class="Apple-tab-span" style="white-space:pre">			</span>return;</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>}</div>
<div><span class="Apple-tab-span" style="white-space:pre">	</span></div><div><span class="Apple-tab-span" style="white-space:pre">		</span>flink.handle = fb-&gt;handle;</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>if (ioctl(display-&gt;fd, DRM_IOCTL_GEM_FLINK, &amp;flink) &lt; 0) { &nbsp;&nbsp;&nbsp;&lt;&lt;-- **********FAILS**********</div>
<div><span class="Apple-tab-span" style="white-space:pre">			</span>fprintf(stderr, &quot;failed to create buffer\n&quot;); &nbsp; &nbsp;&nbsp;</div><div><span class="Apple-tab-span" style="white-space:pre">			</span>return;</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>}</div>
</div><div>---</div><div>(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.)</div>

------=_Part_2861_5373172.1227592301727--


--===============5907930561293393695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--===============5907930561293393695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
_______________________________________________
Dri-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-users

--===============5907930561293393695==--