On Tue, 05 Jun 2018 19:22:47 +0200 "Juan A. Suarez Romero" <jasua...@igalia.com> wrote:
> On Tue, 2018-06-05 at 12:41 +0100, Daniel Stone wrote: > > Hi Juan, > > > > On 5 June 2018 at 09:51, Juan A. Suarez Romero <jasua...@igalia.com> wrote: > > > > > On Mon, 2018-06-04 at 13:22 +0100, Daniel Stone wrote: > > > > Yes, that's correct, and I believe eglMakeCurrent() does perform that > > > > attachment. The NVIDIA/EGLStreams implementation is extremely broken > > > > in that regard, in a way which does break genuine real-world > > > > applications. We had a long discussion on wayland-devel@ when the > > > > EGLStreams implementation was first posted, detailing the ways in > > > > which their implementation causes genuine problems for real-world > > > > users, and can provoke client deadlocks. I am very opposed to > > > > supporting or codifying that behaviour. > > > > > > So I understand eglSwapBuffers() is required to do the attachment. > > > > It is required to do an attachment, yeah. > > > > Nice. The other failing test in CTS is not calling eglSwapBuffers() > before doing the first wl_gl_window_get_attached_size(), and hence > when we call it we get null values. > > So it seems the fix must be done in CTS, bycalling eglSwapBuffers() > to ensure the window has an attached buffer, before getting the size. Hi, I would like to try to clarify the mental model here. The term "attached" is somewhat of a misnomer. But this may also be confusing, because I am bringing in underlying details of Wayland which no other window system has AFAIK. It is true the Wayland request is called wl_surface_attach(wl_buffer). Alone it does essentially nothing, it requires a wl_surface_commit() to become effective. eglSwapBuffers() always does both before returning, so that is fine. Intuitively "attach" implies that one creates an association between two objects and then one can continue working on the attached object (buffer). This is where the misnomer becomes apparent: it would be better to talk about submitting, not attaching. eglSwapBuffers is submitting the current WIP buffer to the compositor to replace the contents of the Wayland wl_surface (window). One cannot resize or draw into the submitted buffer as long as it is held reserved by the Wayland compositor, to be released with wl_buffer.release event. A Wayland window (wl_surface) has no initial size. Only submitting (attach+commit) a wl_buffer will give the wl_surface a size, that is, calling eglSwapBuffers resizes the window. Only the client itself can resize the window e.g. by calling eglSwapBuffers, the compositor or any third party cannot resize the window, so there is no way to query the window size via Wayland. From an EGL application point of view, a window has two different concepts of size: the size that is currently being used (with e.g. input events) which is the size of the wl_surface and returned by wl_egl_window_get_attached_size(); and the size of your current unfinished drawing which will become the wl_surface size on the next call to eglSwapBuffers. wl_egl_window_get_attached_size() would more appropriately be described as returning the size of the last submitted buffer. When I talked about wl_surface size in the above, I was actually using a generally incorrect simplification. The wl_buffer size determines the wl_surface size (now I am using the specific Wayland terms here), but they may not be equal. Buffer scale and transform and wl_viewport are Wayland protocol features that change how the wl_surface size is computed from the wl_buffer size. However, all these are outside of EGL, in the EGL user instead, and EGL itself will be unaware of these. Therefore EGL Wayland can only concern itself with buffer dimensions, the actual wl_surface size will remain unknown to it. Therefore, when interpreting the EGL specifications, when it talks about "window size", on Wayland you can really only think about the WIP or submitted buffer size. I would say that for EGL purposes, the current native window size is the last submitted buffer size and it is zero initially. For the CTS, one may want to test wl_egl_window_get_attached_size and the WIDTH/HEIGHT queries separately to ensure both are as expected (I agree to Daniel's interpretation here). Thanks, pq
pgpm3_heJi0F4.pgp
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev