Post by Dave AirlieSo nvidia have indicated they would like to use an EGLstreams based
solution to enable wayland on their binary driver stack at some point.
As per their recent XDC talk, they sounded like they had given up on
eglstreams for implementing the Wayland protocol and were planning on
doing Wayland for real inside their driver. However, it did sound
like they were planning on using streams for their "I can't believe
it's not GBM" device abstraction. Which are you referring to here?
They each come with different issues.
Post by Dave AirlieI'm just trying to gauge how people in mesa/wayland feel about this as
a solution, is it a solution looking for a problem, when you have
EGLstreams everything looks like a nail type situation etc
For implementing Wayland, I think it's a terrible plan. It would
probably work in the same sense that android's NativeWindow
abstraction works; it doesn't. I've got a rather lengthy post on how
one seemingly subtle design choice makes it impossible to implement
Wayland correctly on top of android's abstractions:
http://www.jlekstrand.net/jason/projects/wayland/wayland-android/ I
haven't seen that particular issue with EGLStreams yet, but that
doesn't mean there isn't one and until I see an implementation, I'm
going to be skeptical. I could also go on a rant about drivers doing
IPC and how it takes fewer lines of code to implement Wayland in a
driver than there are lines of EGLStream spec, but I'll leave that to
someone else. :-)
For interfacing with KMS, I think it's similarly bad. It would work
for the basics of "put image on screen" but not for the more complex
use-cases. For example, a Wayland compositor wants to be able to grab
frames of a client and flip them independantly as planes. How does
this work with a stream? Do you get a stream from a wl_surface and
then just switch to the driver handling everything and the compositor
ignoring it and then switch back? Do you create a stream from a
single wl_buffer? Do you have some way that you can take buffers and
put them on a stream? It seems very ill-defined.
I think (and this is me speculating) is that the reason nvidia wants
to use streams is because their binary driver is *very*
userspace-heavy. On the other hand, most of the FOSS drivers have
substantial kernel components that handle buffer allocation and
arbitrate between clients. For a primarily userspace driver, streams
makes a lot of sense because it's all hidden in the driver and they
can put it wherever they want. For a heavily userspace driver,
userspace modesetting in X also makes a lot of sense...
Post by Dave AirlieAlso if anyone has any idea if any other EGL vendors are heading down
this road, or if this is a one-company extension, ratified to KHR
because nobody objected.
I can't speak to that one.
--Jason