<div dir="ltr"><div>It's at a lower level than translating GLX to EGL. The client renders into specific card-buffers given its hardware-specific drivers inside mesa, and then passes a handle to those buffers to what it thinks is the X server using the DRI3 protocol. Xwayland can in turn pass those buffers to the real Wayland compositor using the secret wl_drm interface.<br>
<br></div>I'm told that the nouveau and radeon drivers now have support for DRI3 as of last week.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 10:17 AM, Sylvain BERTRAND <span dir="ltr"><<a href="mailto:sylware@legeek.net" target="_blank">sylware@legeek.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Jul 04, 2014 at 09:48:20AM -0400, Jasper St. Pierre wrote:<br>
> Xwayland has DRI3/Present support, which means that any app that uses DRI3<br>
> will work fine under it. Right now, this is the Intel driver, with support<br>
> for the other FOSS drivers coming soon.<br>
><br>
> Otherwise, we fall back to non-hardware-accelerated codepaths. It won't<br>
> break, but it will mean that you won't get hardware-accelerated rendering.<br>
<br>
</div>This is good news.<br>
<br>
I need just a bit more of your lights on the matter: the wayland dri3 driver is<br>
intel specific. You mean that it needs hw specific paths? The<br>
mapping of xorg/glx/GL calls into wayland/egl/gl must inclue hw<br>
specifities?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sylvain<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div>