- 15 Mar, 2022 3 commits
-
-
Without this, xwl_present_reset_timer would call xwl_present_timer_callback if the timer was originally armed over a second ago. xwl_present_timer_callback would call xwl_present_msc_bump, which could end up hooking up the window to xwl_window->frame_callback_list again. This would lead to use-after-free in xwl_present_cleanup: Invalid write of size 8 at 0x42B65C: __xorg_list_del (list.h:183) by 0x42B693: xorg_list_del (list.h:204) by 0x42C041: xwl_present_cleanup (xwayland-present.c:354) by 0x423669: xwl_destroy_window (xwayland-window.c:770) by 0x4FDDC5: compDestroyWindow (compwindow.c:620) by 0x5233FB: damageDestroyWindow (damage.c:1590) by 0x501C5F: DbeDestroyWindow (dbe.c:1326) by 0x4EF35B: FreeWindowResources (window.c:1018) by 0x4EF687: DeleteWindow (window.c:1086) by 0x4E24B3: doFreeResource (resource.c:885) by 0x4E2ED7: FreeClientResources (resource.c:1151) by 0x4ACBA4: CloseDownClient (... -
Olivier Fourdan authored
When a window is unrealized, Xwayland would destroy the Wayland surface prior to unrealizing the present window. xwl_present_flip() will then do a wl_surface_commit() of that surface, hence causing a use-after-free: Invalid read of size 8 at 0x49F7FD4: wl_proxy_marshal_array_flags (wayland-client.c:852) by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784) by 0x42B877: wl_surface_commit (wayland-client-protocol.h:3914) by 0x42CAA7: xwl_present_flip (xwayland-present.c:717) by 0x42CD0E: xwl_present_execute (xwayland-present.c:783) by 0x42C26D: xwl_present_msc_bump (xwayland-present.c:416) by 0x42C2D1: xwl_present_timer_callback (xwayland-present.c:433) by 0x42BAC4: xwl_present_reset_timer (xwayland-present.c:149) by 0x42D1F8: xwl_present_unrealize_window (xwayland-present.c:945) by 0x4230E2: xwl_unrealize_window (xwayland-window.c:616) by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292) by 0x4F3F5C: UnrealizeTree (window.c:2805) Address 0x1390b8d8 is 24 bytes inside a block of size 80 free'd at 0x48470E4: free (vg_replace_malloc.c:872) by 0x49F8029: wl_proxy_destroy_caller_locks (wayland-client.c:523) by 0x49F8029: wl_proxy_marshal_array_flags (wayland-client.c:861) by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784) by 0x421984: wl_surface_destroy (wayland-client-protocol.h:3672) by 0x423052: xwl_unrealize_window (xwayland-window.c:599) by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292) by 0x4F3F5C: UnrealizeTree (window.c:2805) by 0x4F424B: UnmapWindow (window.c:2863) by 0x4EF58C: DeleteWindow (window.c:1075) by 0x4E24B3: doFreeResource (resource.c:885) by 0x4E2ED7: FreeClientResources (resource.c:1151) by 0x4ACBA4: CloseDownClient (dispatch.c:3546) Block was alloc'd at at 0x4849464: calloc (vg_replace_malloc.c:1328) by 0x49F7F29: zalloc (wayland-private.h:233) by 0x49F7F29: proxy_create (wayland-client.c:422) by 0x49F7F29: create_outgoing_proxy (wayland-client.c:664) by 0x49F7F29: wl_proxy_marshal_array_flags (wayland-client.c:831) by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784) by 0x4218CA: wl_compositor_create_surface (wayland-client-protocol.h:1291) by 0x422A0D: ensure_surface_for_window (xwayland-window.c:445) by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647) by 0x5232D6: damageSetWindowPixmap (damage.c:1565) by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129) by 0x4EDB3F: TraverseTree (window.c:441) by 0x4FC851: compSetPixmap (compwindow.c:151) by 0x4F8C1A: compAllocPixmap (compalloc.c:616) by 0x4FC938: compCheckRedirect (compwindow.c:174) To avoid that, call xwl_present_unrealize_window() before destroying the Wayland surface. Signed-off-by:Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 42113ab2)
-
Olivier Fourdan authored
The composite overlay window (COW) can be queried from any X11 client, not just the X11 compositing manager. If a client tries to get the composite overlay window, the Xserver will map the window and block all pointer events (the window being mapped and on top of the stack). To avoid that issue, unset the "mapped" state of the composite overlay window once realized when Xwayland is running rootless. Note: All Xservers are actually affected by this issue, but with most regular X servers, the compositing manager will take care of dealing with the composite overlay window, and an X11 client using GetOverlayWindow() won't break pointer events for all X11 clients. Wayland compositors however usually run Xwayland rootless and have no use for the COW. v2: Avoid registering damage for the COW (Michel) v3: Remove the "mapped" test to avoid calling register_damage() if the COW is not mapped (Michel) Closes: #1314 Signed-off-by:
-
- 11 Feb, 2022 2 commits
-
-
Olivier Fourdan authored
When using colored X11 cursors, the colors would appear wrong, yellow would show white, green would show as cyan, and blue would show black whereas red would show fine. This is because the code expanding the cursor data accounts for green for both green and blue channels. Funnily this bug has been there from the beginning. Fix the issue by correctly account for the color channels. Closes: #1303 Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
-
If the Wayland compositor doesn't send a pending frame event, e.g. because the Wayland surface isn't visible anywhere, it could happen that the timer kept getting pushed back and never fired. This resulted in an enormous list of pending vblank events, which could take minutes to process when the frame event finally arrived. Closes: #1110 Reviewed-by:
Jaap Buurman <jaapbuurman@gmail.com> (cherry picked from commit 288ec0e0)
-
- 14 Dec, 2021 5 commits
-
-
Olivier Fourdan authored
Signed-off-by: -
ZDI-CAN-14192, CVE-2021-4008 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
Povilas Kanapickas <povilas@radix.lt> (cherry picked from commit ebce7e2d)
-
ZDI-CAN-14951, CVE-2021-4010 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
ZDI-CAN-14950, CVE-2021-4009 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
ZDI-CAN-14952, CVE-2021-4011 This vulnerability was discovered and the fix was suggested by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
-
- 02 Dec, 2021 4 commits
-
-
Olivier Fourdan authored
Currently, when given the choice, Xwayland will pick the GBM backend over the EGLstream backend if both are available, unless the command line option “-eglstream” is specified. The NVIDIA proprietary driver had no support for GBM until driver series 495, but starting with the driver series 495, both can be used. But there are other requirements with the rest of the stack, typically Mesa, egl-wayland, libglvnd as documented in the NVIDIA driver. So if the NVIDIA driver series 495 gets installed, Xwayland will pick the GBM backend even if EGLstream is available and may fail to render properly. To avoid that issue, prefer EGLstream if EGLstream and all the Wayland interfaces are available, and fallback to GBM automatically unless “-eglstream” was specified. With this, the compositor, given the choice, can decide which actual backend Xwayland would use by advertising (or not) the Wayland "wl_eglstream_controller" interface. This change has no impact on compositors which do not have support for EGLstream in the first place. Signed-off-by:
-
Olivier Fourdan authored
Add (verbose) statements to trace the actual backend used with glamor. That can be useful for debugging. Signed-off-by:
-
Olivier Fourdan authored
On a normal startup sequence, the Xwayland glamor backend would log an error whenever a required Wayland protocol is missing. Those are not really errors though, more informational messages along the glamor backend selection process. Demote those errors to verbose messages to reduce the verbosity of Xwayland at startup by default. Signed-off-by:
Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 30d0d4a1)
-
Olivier Fourdan authored
If no EGLstream capable device is found at startup, Xwayland's EGLstream backend will log an error message "glamor: No eglstream capable devices found". However, considering that the vast majority of drivers do not implement EGLstream, the lack of EGLstream capable device is more of the norm than the exception. Change the error message to a log verbose message. Signed-off-by:
-
- 17 Nov, 2021 1 commit
-
-
We were storing the pointer to struct glamor_context. However, glamor itself is storing the EGLContext pointer since the commit below. Since the two values could never be equal, this resulted in constant superfluous eglMakeCurrent calls. The implicit glFlush triggered by those couldn't be good for performance. Fixes: 7c88977d "glamor: Store the actual EGL/GLX context pointer in lastGLContext" Reviewed-by:
-
- 08 Nov, 2021 1 commit
-
-
Olivier Fourdan authored
Signed-off-by:
-
- 21 Oct, 2021 2 commits
-
-
Olivier Fourdan authored
Xwayland 21.1.3 release candidate 1. Signed-off-by: -
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:
-
- 20 Oct, 2021 1 commit
-
-
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:
Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit 35c5664f)
-
- 18 Oct, 2021 5 commits
-
-
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:
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: -
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:
-
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:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
The xdg_output wasn't cleaned up when destroying the xwl_output. Signed-off-by:
-
- 09 Jul, 2021 3 commits
-
-
-
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:
-
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:
-
- 30 Jun, 2021 3 commits
-
-
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 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:
-
- 21 Jun, 2021 10 commits
-
-
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:
-
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: -
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 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 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:
-
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: #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 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 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 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:
-
