On Fri, Jul 04, 2014 at 10:31:53AM -0400, Jasper St. Pierre wrote:
> 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
> us
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
On Fri, Jul 04, 2014 at 09:48:20AM -0400, Jasper St. Pierre wrote:
> Xwayland has DRI3/Present support, which means that any app that uses DRI3
> will work fine under it. Right now, this is the Intel driver, with support
> for the other FOSS drivers coming soon.
>
> Otherwise, we fall back to non-
Xwayland has DRI3/Present support, which means that any app that uses DRI3
will work fine under it. Right now, this is the Intel driver, with support
for the other FOSS drivers coming soon.
Otherwise, we fall back to non-hardware-accelerated codepaths. It won't
break, but it will mean that you won
On Fri, Jul 04, 2014 at 03:14:43PM +0200, Kalrish Bäakjen wrote:
> If I have understood you correctly, GLX (the means for setting up an OpenGL
> context under X) will interact with the XWayland instance, which will then,
> in turn, interact with the Wayland compositor, giving it the image rendered
If I have understood you correctly, GLX (the means for setting up an OpenGL
context under X) will interact with the XWayland instance, which will then,
in turn, interact with the Wayland compositor, giving it the image rendered
by its client. So, AFAIK, legacy applications that use GLX should work
Hi,
I quickly saw that there is a effort to put xorg on wayland, which
is the correct migration path.
My concern is, it seems, to be limited to basic x11.
What about xorg/GLX/GL on top of wayland?
regards,
--
Sylvain BERTRAND
___
wayland-devel mailing
