Commits on Source (16)
-
Erik Kurzinger authored
If a window is being used for direct rendering with OpenGL or Vulkan, and is using the flipping path for presentation, it's pixmap will be set to a dma-buf backed pixmap created by the client-side GL driver. However, this means that xwl_glamor_eglstream_post_damage won't work since it requires that the pixmap has an EGLSurface that it can render to, which dma-buf backed pixmaps do not. In this case, though, xwl_glamor_eglstream_post_damage is not necessary since glamor will have rendered directly to the pixmap, so we can simply pass it directly to the compositor. There's no need for the intermediate copy we normally do in that function. Therefore, this change adds an early-return case to post_damage for dma-buf backed pixmaps, and removes the corresponding asserts from that function and allow_commits. Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> Acked-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
EGLStream wl_eglstream_display_create_stream() may fail, yet Xwayland would try to attach the buffer which may cause a fatal Wayland protocol error raised by the compositor. Check if the buffer creation worked, and fail gracefully otherwise (like wayland-eglsurface does). Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
If the buffer is NULL, do not even try to attach it, and risk a Wayland protocol error which would be fatal to us. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
Currrently, when a GL error is triggered, glamor would log the error which may not be sufficient to trace it back to the cause of the error. Also dump the backtrace which may give more information as to where the error comes from. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> xorg/xserver#1156
-
Olivier Fourdan authored
If the glamor backend failed to post damage, the caller should do the same to avoid a failure to attach the buffer to the Wayland surface. Change the API of Xwayland's glamor backend post_damage() to return a status so that xwl_window_post_damage() can tell whether the callee failed. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
The EGLStream backend would sometime generate GL errors trying to draw to the framebuffer, which gives an invalid buffer, which in turn would generate a Wayland error from the compositor which is fatal to the client. Check the framebuffer status and bail out early if it's not complete, to avoid getting into trouble later. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
Some functions are called "callback" whereas they are not longer callback functions or "unref" while they no longer deal with a reference counter anymore, which is quite confusing. Rename those functions to be more explicit. Also, the pending streams can be destroyed in different places, move the common code to separate function to avoid duplicating code and help with readability of the code. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Acked-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
eglCreateStreamKHR() can fail and return EGL_NO_STREAM_KHR, in which case there is no point in trying to create a buffer from it. Similarly, eglCreateStreamProducerSurfaceKHR() also fail and return EGL_NO_SURFACE, which in turn will be used in eglMakeCurrent() as draw/read surface, and therefore would mean no draw/read buffer. In those cases, log the error, and bail out early. That won't solve the issue but will help with investigating the root cause of issues with EGLStream backend. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
Previously, we would have pending streams associated with top level X11 windows, keeping temporary accounting for the pending streams before they get fully initialized for the xwl_pixmap which would be associated with X11 pixmaps. If the window content changes before the stream is ready, the corresponding pending stream would be marked as invalid and the pending stream would be eventually removed once the stream becomes ready. Since commit affc4745 - "xwayland: Drop the separate refcount for the xwl_pixmap", we no longer keep a separate reference counter for the xwl_pixmap, but rather tie it to the X11 pixmap lifespan. Yet, the pending stream would still be associated with the X11 toplevel window. Dissociate the pending streams from the X11 toplevel window, to keep it tied only to the xwl_pixmap so that we can have: - pixmap <-> xwl_pixmap - xwl_pixmap <-> pending stream Of course, the pending streams remain temporary and get removed as soon as the ready callback is triggered, but the pending streams are not linked to the X11 window anymore which can change their content, and therefore their X11 pixmap at any time. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
Commit affc4745 - "xwayland: Drop the separate refcount for the xwl_pixmap" removed the separate reference counter for the xwl_pixmap which holds the EGLStream. While that works fine for the common case, if the window's pixmap is changed before the stream is ready, the older pixmap will be destroyed and the xwl_pixmap along with it, even if the compositor is still using the stream. The code that was removed with commit affc4745 was taking care of that by increasing the separate reference counter for the xwl_pixmap, but it no longer the case. As a result, we may end up with the EGL stream in the wrong state when trying to use it, which will cascade down into all sort of issues. To avoid the problem, increase the reference count on the pixmap when it is marked as invalid in EGLStream's SetWindowPixmap(). This way, the xwl_pixmap and the EGLStream are kept until released by the compositor, even when the pixmap changes before stream is ready. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Fixes: affc4745 xwayland: Drop the separate refcount for the xwl_pixmap #1156
-
Olivier Fourdan authored
Now that the pending stream is associated with the xwl_pixmap for EGLStream and the xwl_pixmap itself is associated to the pixmap, we have a reliable way to get to those data from any pending stream. As a result, the list of pending streams that we keep in the EGLStream global structure becomes useless. So we can drop the pending stream's xwl_pixmap and also the list of pending streams altogether, and save us a walk though that list for each callback. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Suggested-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
The EGL surface for the xwl_pixmap is created once the stream is ready and valid. If the pixmap's EGL surface fails, for whatever reason, the xwl_pixmap will be unusable and will end up as an invalid wl_buffer. Make sure we do not allow commits in that case and recreate the xwl_pixmap/stream. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> #1156
-
Olivier Fourdan authored
Use calloc() instead of malloc() like the rest of the code. Also fix the arguments of calloc() calls to match the definition which is calloc(size_t nmemb, size_t size). This is a cleanup patch, no functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
EGLstream's post_damage() would unconditionally return success regardless of the actual status of the eglSwapBuffers(). Yet, if eglSwapBuffers() fails, we should not post the corresponding damage as they wouldn't match the actual content of the buffer. Use the eglSwapBuffers() return value as the return value for post_damage() and do not take a refrence on the pixmap if it fails. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
Currently, the EGLstream backend would increment the pixmap refcount for each commit, and decrease that refcount on the wl_buffer release callback. But that's relying on the compositor sending us a release callback for each commit, otherwise the pixmap refcount will keep increasing and the pixmap will be leaked. So instead, increment the refcount on the pixmap only when we have not received a release notification for the wl_buffer, to avoid increasing the pixmap refcount more than once without a corresponding release event. This way, if the pixmap is still in use when released on the X11 side, the EGL stream will be kept until the compositor releases it. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Suggested-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
The EGLstream backend's post damage function uses a shader and glDrawArrays() to copy the data from the glamor's pixmap texture prior to do the eglSwapBuffers(). However, glDrawArrays() can be affected by the GL state, and therefore not reliably produce the expected copy, causing the content of the buffer to be corrupted. Make sure to set the ALU to GXCopy prior to call glDrawArrays() to get the expected result. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Suggested-by:
Michel Dänzer <mdaenzer@redhat.com>
Showing
- glamor/glamor.c 1 addition, 0 deletionsglamor/glamor.c
- hw/xwayland/xwayland-cursor.c 9 additions, 2 deletionshw/xwayland/xwayland-cursor.c
- hw/xwayland/xwayland-glamor-eglstream.c 248 additions, 124 deletionshw/xwayland/xwayland-glamor-eglstream.c
- hw/xwayland/xwayland-glamor.c 4 additions, 2 deletionshw/xwayland/xwayland-glamor.c
- hw/xwayland/xwayland-glamor.h 2 additions, 2 deletionshw/xwayland/xwayland-glamor.h
- hw/xwayland/xwayland-present.c 6 additions, 1 deletionhw/xwayland/xwayland-present.c
- hw/xwayland/xwayland-window.c 11 additions, 2 deletionshw/xwayland/xwayland-window.c
This diff is collapsed.