OpenGL in USB Display Devices under wayland

[rektide]

On Fri, Jun 22, 2012 at 01:14:00PM -0400, Casey Dahlin wrote:
> On Fri, Jun 22, 2012 at 09:40:43PM +0530, Sannu K wrote:
> > After seeing the changes made in X server for offloading hardware
> > acceleration for USB display devices (displaylink and others), I am curious
> > to know about how Wayland takes care (if at all it does) of offloading
> > hardware acceleration to primary GPU. X server uses primary GPU (intel or
> > nvidia or ati) for 3D acceleration and just sends the scan out buffer to
> > USB display device. As far as I went through the architecture of wayland I
> > am not able to find where this fits in and how. Please provide some info on
> > how this is (or will be) done.
> > 
> 
> Wayland is just a protocol for exchanging buffers between apps and compositors.
> It pushes concerns like this onto libraries.
> 
> Basically the client application just asks the compositor for a DRM buffer, and
> the compositor turns around and asks mesa for it, then hands it back to the
> application. Then the app uses mesa to draw on the DRM buffer without any
> intervention from the compositor at all. When its done it signals the
> compositor, which again uses mesa to render the buffer onto a master screen
> surface, then hands it to libdrm for scanout.
> 
> The compositor itself isn't even part of wayland. Rather we expect each desktop
> environment will implement their own (though the workflow for 3D should be the
> same, and the weston example compositor demonstrates it if you need a working
> example). Wayland is just a tiny protocol to coordinate the buffer exchanges
> between the two apps. All of the graphics-related stuff is in mesa or libdrm.

This seems more like a re-statement of what Wayland is presently used for than in any way
indicative of how Wayland could be used to accomplish the stated goal: a compositor that
knows how to ship the buffer across devices.

The inference I'm getting from your email says to me mostly, "it's just the compositor, it
can do what it want."

How about this question: might Weston be adaptable to serve this use case? What would be the
major changes to Weston to do this? What other subsystems would have to change?

-r