<div dir="ltr"><div>Right, glamor used to be ported to a PVR platform which is the only</div><div>non-mesa platform we tried to support. And I don't think that platform</div><div>will support DRI3 currently. And that platform also doesn't have</div>
<div>gbm library.</div><div><br></div><div>IMO, to make the DRI3 support depend on libgbm version 9 should</div><div>be good enough currently. I can't think of a case which has libgbm</div><div>version 9 but has an incompatible EGLNativePixmapType. Is there any</div>
<div>of such real case?</div><div><br></div><div>Thanks,</div><div>Zhigang Gong.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 14, 2013 at 11:20 AM, Gaetan Nadon <span dir="ltr"><<a href="mailto:memsize@videotron.ca" target="_blank">memsize@videotron.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div>On 13-12-12 05:56 PM, Gaetan Nadon
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On 13-12-12 01:55 AM, Michel Dänzer wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre>Well, when I meant 'linked', I was more thinking 'associated'.
</pre>
          <blockquote type="cite">
            <pre>For example: <a href="http://git.ti.com/glsdk/libgbm/trees/master" target="_blank">http://git.ti.com/glsdk/libgbm/trees/master</a> allows
any gl driver to implement gbm.
I expect that at compilation time we get the right headers,
and then we would have tested correctly what is EGLNativePixmapType.
</pre>
          </blockquote>
        </blockquote>
        <pre>If you check this at build time, the resulting glamor binaries will only
work with the same EGL/gbm implementation they were built against, won't
they? That doesn't seem very nice e.g. for Linux distros.
</pre>
      </blockquote>
      <pre>Thanks for raising the question. I could not find a non-mesa
implementation. Strictly from a package configuration point of view, it
is acceptable to limit what the package can cope with. I suspect
glamor_egl.c cannot handle unknown EGLNativePixmapType(s).

It is generally preferred to detect problems early in the configuration
rather than at build time or at runtime. Whether glamor should be able
to support all current and future implementations is a separate discussion.
_______________________________________________
Glamor mailing list
<a href="mailto:Glamor@lists.freedesktop.org" target="_blank">Glamor@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/glamor" target="_blank">http://lists.freedesktop.org/mailman/listinfo/glamor</a>
</pre>
    </blockquote></div></div>
    I think I found a non-mesa implementation, reading the patch "GLX:
    Enable glx support."<br>
    <blockquote>"If you are not using normal MESA, for example PVR's
      private GLES
      implementation, then it should be ok to use GLES2 glamor and the
      GLX should work as expected. In this commit, I use gbm to check
      whether we are using MESA or non-mesa. Maybe not the best way."<br>
    </blockquote>
    That would be the PowerVR INsider SDK
    "<a href="http://www.imgtec.com/powervr/insider/sdkdownloads/" target="_blank">www.imgtec.com/powervr/insider/sdkdownloads/</a>"<br>
    <br>
    <br>
    <br>
    <br>
  </div>

<br>_______________________________________________<br>
Glamor mailing list<br>
<a href="mailto:Glamor@lists.freedesktop.org">Glamor@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/glamor" target="_blank">http://lists.freedesktop.org/mailman/listinfo/glamor</a><br>
<br></blockquote></div><br></div>