- Nov 08, 2021
-
-
Olivier Fourdan authored
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
-
- Oct 21, 2021
-
-
Olivier Fourdan authored
Xwayland 21.1.3 release candidate 1. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
-
Olivier Fourdan authored
The xwayland-piglit.sh script spawns weston, runs run-piglit.sh and finally kills weston. However, this whole script is running with “-e” meaning that any error will cause the script to exit immediately. As a result, if run-piglit.sh exits with a non-zero code such as 77 for skipping the test, the script will exit prematurely leaving weston running, and meson will simply wait until the timeout kicks in, and fail eventually instead of skipping the test as it should. Fix this by removing the option to exit immediately prior to spawn the script run-piglit.sh. Closes: #1204 Suggested-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit f37d11cd)
-
- Oct 20, 2021
-
-
Olivier Fourdan authored
If the tablet tool is moved out of proximity before the cursor's pending frame callback is received, any further attempts to update the cursor will fail because the frame callback is still pending. Make sure to clear any cursor pending frame when the tool gets in proximity again, similar to what we do when the pointer re-enters a surface, so that the cursor updates aren't discarded. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/1969 Reviewed-by: Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit 35c5664f)
-
- Oct 18, 2021
-
-
Olivier Fourdan authored
With the GBM backend becoming usable with different drivers such as NVIDIA, set the GLVND vendor to the same value as the GBM backend name. Mesa implementation however returns "drm" so we need to special case this value - Basically, for anything other than "drm" we simply assume that the GBM backend name is the same as the vendor. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Tested-by: James Jones <jajones@nvidia.com> (cherry picked from commit 5daf42b4)
-
Xwayland was passing GBM bos directly to eglCreateImageKHR using the EGL_NATIVE_PIXMAP_KHR target. Given the EGL GBM platform spec claims it is invalid to create a EGLSurface from a native pixmap on the GBM platform, implying there is no mapping between GBM objects and EGL's concept of native pixmaps, this seems a bit questionable. This change modifies the bo import function to extract all the required data from the bo and then imports it as a dma-buf instead when the dma-buf + modifiers path is available. Signed-off-by: James Jones <jajones@nvidia.com> Reviewed-by: Simon Ser <contact@emersion.fr> (cherry picked from commit f1572937)
-
Olivier Fourdan authored
Xwayland's xwl_shm_create_pixmap() computes the size of the shared memory pool to create using a size_t, yet the Wayland protocol uses an integer for that size. If the pool size becomes larger than INT32_MAX, we end up asking Wayland to create a shared memory pool of negative size which in turn will raise a protocol error which terminates the Wayland connection, and therefore Xwayland. Avoid that issue early by return a NULL pixmap in that case, which will trigger a BadAlloc error, but leave Xwayland alive. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 079c5ccb)
-
Since 8702c938 the pixmap formats are handled in a single place. In the process of conversion the difference between pixmap formats that can be uploaded and those that can be rendered on GL side has been lost. This affects only 1-bit pixmaps: as they aren't supported on GL, but can be converted to a R8 or A8 format for rendering (see glamor_get_tex_format_type_from_pictformat()). To work around this we add a separate flag that specifies whether the format actually supports rendering in GL, convert all checks to use this flag and then add 1-bit pixmap formats that don't support rendering in GL. Fixes: 8702c938 Closes: #1210 Acked-by: Olivier Fourdan <ofourdan@redhat.com> Tested-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Povilas Kanapickas <povilas@radix.lt> (cherry picked from commit e59e24c8)
-
The xdg_output wasn't cleaned up when destroying the xwl_output. Signed-off-by: Simon Ser <contact@emersion.fr> (cherry picked from commit 6f63873d)
-
- Jul 09, 2021
-
-
Michel Dänzer authored
-
Michel Dänzer authored
This makes sure RandR events are sent to interested clients as needed. This was happening implicitly in some cases, but not in others, e.g. if the root window size didn't change. If this were to call RRTellChanged more often than necessary in some cases, that should be harmless, as it only sends events if something has actually changed since last time. Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1979892 . v2: * Call RRTellChanged at the very end of update_screen_size, just in case. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 204f10c2)
-
Michel Dänzer authored
This can happen if RRTellChanged is called during initialization. Continuing in that case makes no sense conceptually: * Any event sent over the wire requires a corresponding window. * No root window probably means there can't be any clients which could receive the events. In practice, it would result in a crash down the road due to dereferencing the NULL ScreenRec::root pointer. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit a6d178b6)
-
- Jun 30, 2021
-
-
Michel Dänzer authored
Xwayland 21.1.2 release candidate 1.
-
Olivier Fourdan authored
To avoid an EGL stream in the wrong state, if the window pixmap changed before the stream was connected, we would still keep the pending stream but mark it as invalid. Once the callback is received, the pending would be simply discarded. But all of this is actually to avoid a bug in egl-wayland, there should not be any problem with Xwayland destroying an EGL stream while the compositor is still using it. With that bug now fixed in egl-wayland 1.1.7, we can safely drop all that logic from Xwayland EGLstream backend. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Closes: xorg/xserver#1189 (cherry picked from commit 7d509b6f)
-
Olivier Fourdan authored
If the pixmap does not actually change in set_window_pixmap(), there is no need to invalidate the pending stream, if there's one. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Suggested-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 2be9f795)
-
- Jun 21, 2021
-
-
Olivier Fourdan authored
Currently, xorgGlxMakeCurrent() would set the context tag only for indirect GLX contexts. However, several other places expect to find a context for the tag or they would raise a GLXBadContextTag error, such as WaitGL() or WaitX(). Set the context tag for direct contexts as well, to avoid raising an error and possibly killing the client and set currentClient. Thanks to Erik Kurzinger <ekurzinger@nvidia.com> for spotting the issue. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit c468d34c) (cherry picked from commit aad61e8e)
-
If a GLXMakeCurrent request specifies an X window as its drawable, __glXGetDrawable will implicitly create a GLXWindow for it. However, the client may have already explicitly created a GLXWindow for that X window. If that happens, two __glXDrawableRes resources will be added to the window. If the explicitly-created GLXWindow is later destroyed by the client, DrawableGone will call FreeResourceByType on the X window, but this will actually free the resource for the implicitly-created GLXWindow, since that one would be at the head of the list. Then if the X window is destroyed after that, the resource for the explicitly-created GLXWindow will be freed. But that GLXWindow was already destroyed above. This crashes the server when it tries to call the destroyed GLXWindow's destructor. It also means the implicitly-created GLXWindow would have been leaked since the FreeResourceByType call mentioned above skips calling the destructor. To fix this, if __glXGetDrawable is given an X window, it should check if there is already a GLXWindow associated with it, and only create an implicit one if there is not. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit b7a85e44)
-
Olivier Fourdan authored
That will dramatically affect performance, might as well log when we cannot use GL_OES_EGL_image with the NVIDIA closed-source driver. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 34a58d77)
-
Olivier Fourdan authored
If the EGLStream backend is able to use hardware acceleration with the NVIDIA closed source driver, we should use the "nvidia" GLX implementation instead of the one from Mesa to take advantage of the NVIDIA hardware accelerated rendering. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit fae58e9b)
-
Olivier Fourdan authored
If Xwayland's EGLstream backend supports hardware acceleration with the NVIDIA closed-source driver, the GLX library also needs to be one shipped by NVIDIA, that's what GLVND is for. Add a new member to the xwl_screen that the backend can optionally set to the preferred GLVND vendor to use. If not set, "mesa" is assumed. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 24fc8aea)
-
When eglSwapBuffers inserts a new frame into a window's stream, there may be a delay before the state of the consumer end of the stream is updated to reflect this. If the subsequent wl_surface_attach, wl_surface_damage, wl_surface_commit calls are received by the compositor before then, it will (typically) re-use the previous frame acquired from the stream instead of the latest one. This can leave the window displaying out-of-date contents, which might never be updated thereafter. To fix this, after calling eglSwapBuffers, xwl_glamor_eglstream_post_damage should call eglStreamFlushNV. This call will block until it can be guaranteed that the state of the consumer end of the stream has been updated to reflect that a new frame is available. Closes: xorg/xserver#1171 Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> (cherry picked from commit 7515c23a)
-
As of commit 098e0f52 xwl_glamor_eglstream_allow_commits will not allow commits if the xwl_pixmap does not have an EGLSurface. This is valid for pixmaps backed by an EGLStream, however pixmaps backed by a dma-buf for OpenGL or Vulkan rendering will never have an EGLSurface. Unlike EGLStream backed pixmaps, though, glamor will render directly to the buffer that Xwayland passes to the compositor. Hence, they don't require the intermediate copy in xwl_glamor_eglstream_post_damage that EGLStream backed pixmaps do, so there is no need for an EGLSurface. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 3d33d885)
-
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> (cherry picked from commit 012350e3)
-
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> (cherry picked from commit d85bfa6a)
-
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> (cherry picked from commit b583395c)
-
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> (cherry picked from commit a4579997)
-
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> xorg/xserver#1156 (cherry picked from commit 098e0f52)
-
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> (cherry picked from commit bee2ebb2)
-
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 xorg/xserver#1156 (cherry picked from commit e19bf86c)
-
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> xorg/xserver#1156 (cherry picked from commit cb61ecc7)
-
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> xorg/xserver#1156 (cherry picked from commit cc596bcf)
-
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> (cherry picked from commit 823f3254)
-
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> xorg/xserver#1156 (cherry picked from commit 85244d2a)
-
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> xorg/xserver#1156 (cherry picked from commit 252cbad3)
-
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 (cherry picked from commit 3b265c59)
-
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> xorg/xserver#1156 (cherry picked from commit 25d2f494)
-
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> xorg/xserver#1156 (cherry picked from commit 4f0889e9)
-
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> (cherry picked from commit 4f6fbd50)
-
Provides an implementation for the pixmap_from_buffers DRI3 function for xwayland's eglstream backend. This will be used by the NVIDIA GLX driver to pass buffers from client applications to the server. These can then be presented using the PRESENT extension. To hopefully make this less error-prone, we also introduce a "type" field for this struct to distinguish between xwl_pixmaps for the new DRI3-created pixmaps and those for the existing glamor-created pixmaps. Additionally, the patch enables wnmd present mode with the eglstream backend. This involves creating a wl_buffer for the provided dma-buf before importing it into EGL and passing this to the compositor so it can be scanned out directly if possible. Since both backends now support this present mode, the HAS_PRESENT_FLIP flag is no longer needed, so it can be removed. Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> (cherry picked from commit 38e87590)
-
This is preliminary work for hardware accelerated rendering with the NVIDIA driver. This exposes a new glamor backend function, check_flip, which can be used to control whether flipping is supported for the given pixmap. Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> (cherry picked from commit bc99dd21)
-