summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-04-27xwayland/window: Queue damage after commits are allowedxwayland-22.1Jonas Ådahl1-0/+12
Compositors may use XWAYLAND_ALLOW_COMMITS to communicate when Xwayland may or may not commit new buffers to a wl_surface. If commits are denied, then later allowed, we'll only get a buffer attached if there is actual damage posted, which might be long after. This fixes an issue where the window manager would reparent a window while denying commits, then after reparenting, allow commits. The window in question belonged to a game and took several seconds produce the next frame, resulting in an empty window appearing as if it had just disappeared. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 9a55c402aa803fb10e39ab4fd18a709d0cd06fd4)
2023-04-27xwayland/window: Move set-allow functions lower downJonas Ådahl1-35/+35
This will make some helper functions in the same file usable without extra declarations. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 5ce96a2a733b0a6556e1512fd9a703ede6a7c959)
2023-04-27build: set _GNU_SOURCE when checking for SO_PEERCREDSimon Ser1-1/+1
SO_PEERCRED is not POSIX, so might be hidden unless _GNU_SOURCE is defined. See [1]: cc.has_header_symbol() does not inherit the project arguments. [1]: https://github.com/mesonbuild/meson/issues/3301 Signed-off-by: Simon Ser <contact@emersion.fr> (cherry picked from commit 636c9aa359eab45102c12a9fccb8f60587c7d485)
2023-04-27xwayland: Fix build without GBMOlivier Fourdan2-4/+7
The present code in Xwayland cannot be used without GBM, so if GBM is not available (or too old), the build would fail. Make sure we do not use the present code without GBM support. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit da0de3caf62023d2b507ed3d66a0b0daa7104c4a)
2023-04-27glamor: Fix build without GBMOlivier Fourdan1-0/+2
The functions glamor_egl_fd_from_pixmap()/glamor_egl_fds_from_pixmap() are not available without GBM support. So if GBM is not available or too old, the code would fail to link trying to find the references to those functions. Make sure we skip that code when glamor is built without GBM. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit c24910d0e138dc1dc58c0c0cdc10b49a1ed85975)
2023-04-27xwayland: Make Wayland logs non-fatalOlivier Fourdan1-2/+1
The Wayland library may log warnings, we do not need to make that fatal to the Xserver. By killing the Xserver whenever a warning is raised, we hide other log messages that might be also interesting. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 62b1fac0b5c5b9eeeca7a66cba6398c211acc504)
2023-04-27xwayland: Prevent nested xwl_present_for_each_frame_callback callsMichel Dänzer3-2/+30
It could happen with the following call path: frame_callback xwl_present_frame_callback xwl_present_msc_bump xwl_present_execute xwl_present_flip xwl_window_create_frame_callback The nested loop called xwl_present_reset_timer, which may end up calling xorg_list_del for the entry after the one frame_callback started the chain for. This resulted in the outer loop never terminating, because its next element wasn't hooked up to the list anymore. We avoid this by calling xwl_present_reset_timer as needed in frame_callback, and bailing from xwl_window_create_frame_callback if it was called from the former. We also catch nested calls and FatalError if they ever happen again due to another bug. v2: * Leave xwl_present_reset_timer call in xwl_present_frame_callback, needed if xwl_present_msc_bump didn't hook up the window to the frame callback list again. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 (cherry picked from commit 754d6b6dd0a9ec42d75247596a8885bf54352ee7)
2023-04-27xwayland: Refactor xwl_present_for_each_frame_callback helperMichel Dänzer3-27/+20
Preparation for following changes, no functional change intended. (cherry picked from commit 4d1cd7cdc22013ed8de17d3218b9790b7027e1fe)
2023-03-29Bump version to 22.1.9xwayland-22.1.9Olivier Fourdan1-2/+2
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2023-03-29composite: Fix use-after-free of the COWOlivier Fourdan1-0/+5
ZDI-CAN-19866/CVE-2023-1393 If a client explicitly destroys the compositor overlay window (aka COW), we would leave a dangling pointer to that window in the CompScreen structure, which will trigger a use-after-free later. Make sure to clear the CompScreen pointer to the COW when the latter gets destroyed explicitly by the client. This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 26ef545b3502f61ca722a7a3373507e88ef64110)
2023-03-29xkbUtils: use existing symbol names instead of deleted deprecated onesBenno Schulenberg1-2/+2
Symbols `XK_Cyrillic_DZHE` and `XK_Serbian_DZE` were pure synonyms. (cherry picked from commit 6153c71cfb4698f1a416266564ecc748e4a25f2c)
2023-03-27test: Use either wayland-info or weston-infoOlivier Fourdan1-1/+6
weston-info has been deprecated for quite some time, whereas wayland-info may not be available yet. So we use either, depending on what's actually available. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit fc625fe172d9f6a149a594b5214364bedf680239)
2023-03-27glamor: Don't glFlush/ctx switch unless any work has been performedJoshua Ashton4-7/+15
`glamor_make_current` is always called before any calls to GL. Apply some dirty-tracking to whenever we call `glamor_make_current` so that we can avoid a decent amount of redundant GL work on each Dispatch cycle. Gamescope previously was waking up an empty Xwayland server with an XQueryPointer and I noticed a significant amount of churn doing redundant GL work. This has been addressed on the Gamescope side as well, but avoiding any useless GL context switches and flushes when glamor is doing nothing is still beneficial for CPU and power usage on portable devices. Signed-off-by: Joshua Ashton <joshua@froggi.es> Reviewed-by: Emma Anholt <emma@anholt.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com (cherry picked from commit 89163917e1976db4ae4863ad5337fa14bf348081)
2023-02-23present: Send a PresentConfigureNotify event for destroyed windowsAdam Jackson3-4/+19
This enables fixing a deadlock case on the client side, where the client ends up blocked waiting for a Present event that will never come because the window was destroyed. The new PresentWindowDestroyed flag allows the client to avoid blocking indefinitely. Signed-off-by: Adam Jackson <ajax@redhat.com> See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116 See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6685 Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 462b06033e66a32308d940eb5fc47f5e4c914dc0)
2023-02-23xwayland/window: Do not double add window to damage listMinh Phan1-1/+2
The window might be retained in the damage list after `xwl_screen_post_damage` in certain conditions. This means we need to check if the window is already in the list to avoid adding the same window twice which will lead to list corruption resulting in server freeze in `xwl_screen_post_damage`. Signed-off-by: Minh Phan <phanquangminh217@gmail.com> (cherry picked from commit ba644a64a415962956de72936d21b6527ee8cd57)
2023-02-23dix: Clear device sprite after free in AttachDevice()Olivier Fourdan1-0/+1
The code in AttachDevice() may free the dev->spriteInfo->sprite under some circumstances and later call GetCurrentRootWindow() which uses the same dev->spriteInfo->sprite. While it seems unlikely that this is actually an issue, considering the cases where one or the other get called, it still makes the code look suspicious. Make sure to clear set dev->spriteInfo->sprite to NULL immediately after it's freed to avoid any confusion, even if only to clarify the code. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1436 (cherry picked from commit e196535abbf2ef4aa7c1eb0b4b9b67840032b88a)
2023-02-23glamor: Don't initialize on softpipeIvan A. Melnikov2-0/+9
There are systems where softpipe is the default renderer, e.g. when llvmpipe is not is not available. Using glamor on such systems is never a good idea. This mirrors what commit 0a9415cf793babed1f28c61f8047d51de04f1528 did for llvmpipe. Closes: #1417 Signed-off-by: Ivan A. Melnikov <iv@altlinux.org> (cherry picked from commit 711d491729d83b17114fd08d784bc0ddfd17ff6a)
2023-02-23xwayland: Don't expose XRandR emulated modes for leaseable displaysJoshua Ashton1-0/+4
Leasable displays do not have any actual associated Wayland output and are not available to regular X11 clients and left entirely to the application who requests the lease. As these are not actually managed by the Wayland compositor and left entirely to the "lessee" application, the viewporter protocol required for the XRandR emulation is not usable on such devices. We should therefore not advertise the XRandR emulated modes for those leasable displays. This also solves a problem with implementations of glXGetMscRateOML() which is used notably by Chromium/Electron. Applications using this which will begin lagging/stuttering exponentially over time, trying to look up a non-existent mode with 0x0 as returned by XF86VidModeGetModeLine() with XRandR emulation for such devices. See-also: https://github.com/labwc/labwc/issues/553 Signed-off-by: Joshua Ashton <joshua@froggi.es> (cherry picked from commit 0abb5770750e54566d3ce14a3be9dbf15bb578ba)
2023-02-23xwayland/output: properly return the current emulated mode when queriedMinh Phan2-0/+17
This fixes an issue with GLFW-based games failing to set the resolution when the user request to switch back to the native display mode. Signed-off-by: Minh Phan <phanquangminh217@gmail.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 511d1686a6ac3e3e0d66fb67b62620ba2a6575c8)
2023-02-23randr: introduce rrCrtcGetInfo DDX functionMinh Phan2-0/+11
This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo reply. One use case is to allow Xwayland to return the current emulated mode for the specific client instead of the global mode. Signed-off-by: Minh Phan <phanquangminh217@gmail.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 5145742fb6e3d108b05db1521b51112e0dbfb95a)
2023-02-23GLX: Free the tag of the old context laterDoğukan Korkmaztürk1-4/+3
In CommonMakeCurrent() function, the tag of the old context is freed before the new context is made current. This is problematic because if the CommonMakeNewCurrent() function fails, the tag of the old context ends up being removed, even though it is still active. This causes subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to generate a GLXBadContextTag error. This change moves the function call that frees the old tag to a location where the result of CommonMakeNewCurrent() call is known and it is safe to free it. Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com> (cherry picked from commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3)
2023-02-23xwayland/glx: Mirror all EGLConfigsDoğukan Korkmaztürk1-1/+1
Updated the for-loop that iterates over the received EGLConfigs to include the very first EGLConfig with index 0. Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com> Fixes: 8469241592 - xwayland: Add EGL-backed GLX provider (cherry picked from commit 3852b0d10a061348ea8214fbcbef3c5c08cac0b6)
2023-02-23glamor: Only check for llvmpipe rendererCorentin Noël2-2/+2
The virgl driver exposes the name of the host renderer which might be llvmpipe. In this case we still need glamor to be initialized. Only check if the renderer starts with llvmpipe (which is what llvmpipe exposes). Signed-off-by: Corentin Noël <corentin.noel@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit fdebbc60d89cdc1b3353424b6568b25a61dcf372)
2023-02-23xwayland: properly get FDs from multiplanar GBM BOsLucas Stach1-9/+57
Multiplanar GBM buffers can point to different objects from each plane. Use the _for_plane API when possible to retrieve the correct prime FD for each plane. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Simon Ser <contact@emersion.fr> Tested-by: Guido Günther <agx@sigxcpu.org> (cherry picked from commit 7d5ad2d372cc88648f6744c318a4bee18443689d)
2023-02-23xwayland: handle fd export failure in glamor_egl_fds_from_pixmapLucas Stach1-0/+7
Check the fd for validity before giving a success return code. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Simon Ser <contact@emersion.fr> Tested-by: Guido Günther <agx@sigxcpu.org> (cherry picked from commit 951502e49797ab4c5db047e9df32c93d050d64af)
2023-02-07Bump version to 22.1.8xwayland-22.1.8Olivier Fourdan1-2/+2
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2023-02-07Xi: fix potential use-after-free in DeepCopyPointerClassesPeter Hutterer1-1/+3
CVE-2023-0494, ZDI-CAN-19596 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 0ba6d8c37071131a49790243cdac55392ecf71ec)
2023-01-25dix: Use CopyPartialInternalEvent in EnqueueEventMike Gorse1-1/+1
The event might be a DeviceEvent allocated on the stack, in AccessXKeyboardEvent for instance. Fixes out-of-bounds read. Signed-off-by: Mike Gorse <mgorse@suse.com> (cherry picked from commit 2ef5ef57bd37a8bec2ac454053b283c6f87c3b40)
2023-01-25dix: Correctly save replayed event into GrabInfoRecPovilas Kanapickas3-3/+18
When processing events we operate on InternalEvent pointers. They may actually refer to a an instance of DeviceEvent, GestureEvent or any other event that comprises the InternalEvent union. This works well in practice because we always look into event type before doing anything, except in the case of copying the event. *dst_event = *src_event would copy whole InternalEvent event and would cause out of bounds read in case the pointed to event was not InternalEvent but e.g. DeviceEvent. This regression has been introduced in 23a8b62d34344575f9df9d057fb74bfefa94a77b. Fixes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1261 Signed-off-by: Povilas Kanapickas <povilas@radix.lt> (cherry picked from commit 6ef5c05728f8b18170fbc8415d7502495a08670b)
2022-12-19Bump version to 22.1.7xwayland-22.1.7Olivier Fourdan1-2/+2
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2022-12-19Xext: fix invalid event type mask in XTestSwapFakeInputPeter Hutterer1-1/+1
In commit b320ca0 the mask was inadvertently changed from octal 0177 to hexadecimal 0x177. Fixes commit b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63 Xtest: disallow GenericEvents in XTestSwapFakeInput Found by Stuart Cassoff Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit bb1711b7fba42f2a0c7d1c09beee241a1b2bcc30)
2022-12-14Bump to version 22.1.6xwayland-22.1.6Peter Hutterer1-2/+2
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-14xkb: reset the radio_groups pointer to NULL after freeing itPeter Hutterer1-0/+1
Unlike other elements of the keymap, this pointer was freed but not reset. On a subsequent XkbGetKbdByName request, the server may access already freed memory. CVE-2022-4283, ZDI-CAN-19530 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit ccdd431cd8f1cabae9d744f0514b6533c438908c)
2022-12-14Xi: avoid integer truncation in length check of ProcXIChangePropertyPeter Hutterer2-3/+4
This fixes an OOB read and the resulting information disclosure. Length calculation for the request was clipped to a 32-bit integer. With the correct stuff->num_items value the expected request size was truncated, passing the REQUEST_FIXED_SIZE check. The server then proceeded with reading at least stuff->num_items bytes (depending on stuff->format) from the request and stuffing whatever it finds into the property. In the process it would also allocate at least stuff->num_items bytes, i.e. 4GB. The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty, so let's fix that too. CVE-2022-46344, ZDI-CAN 19405 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 8f454b793e1f13c99872c15f0eed1d7f3b823fe8)
2022-12-14Xi: return an error from XI property changes if verification failedPeter Hutterer1-0/+5
Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the property for validity but didn't actually return the potential error. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit b8a84cb0f2807b07ab70ca9915fcdee21301b8ca)
2022-12-14Xext: free the screen saver resource when replacing itPeter Hutterer1-1/+1
This fixes a use-after-free bug: When a client first calls ScreenSaverSetAttributes(), a struct ScreenSaverAttrRec is allocated and added to the client's resources. When the same client calls ScreenSaverSetAttributes() again, a new struct ScreenSaverAttrRec is allocated, replacing the old struct. The old struct was freed but not removed from the clients resources. Later, when the client is destroyed the resource system invokes ScreenSaverFreeAttr and attempts to clean up the already freed struct. Fix this by letting the resource system free the old attrs instead. CVE-2022-46343, ZDI-CAN 19404 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 842ca3ccef100ce010d1d8f5f6d6cc1915055900)
2022-12-14Xext: free the XvRTVideoNotify when turning off from the same clientPeter Hutterer1-1/+3
This fixes a use-after-free bug: When a client first calls XvdiSelectVideoNotify() on a drawable with a TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct is added twice to the resources: - as the drawable's XvRTVideoNotifyList. This happens only once per drawable, subsequent calls append to this list. - as the client's XvRTVideoNotify. This happens for every client. The struct keeps the ClientPtr around once it has been added for a client. The idea, presumably, is that if the client disconnects we can remove all structs from the drawable's list that match the client (by resetting the ClientPtr to NULL), but if the drawable is destroyed we can remove and free the whole list. However, if the same client then calls XvdiSelectVideoNotify() on the same drawable with a FALSE onoff argument, only the ClientPtr on the existing struct was set to NULL. The struct itself remained in the client's resources. If the drawable is now destroyed, the resource system invokes XvdiDestroyVideoNotifyList which frees the whole list for this drawable - including our struct. This function however does not free the resource for the client since our ClientPtr is NULL. Later, when the client is destroyed and the resource system invokes XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On a struct that has been freed previously. This is generally frowned upon. Fix this by calling FreeResource() on the second call instead of merely setting the ClientPtr to NULL. This removes the struct from the client resources (but not from the list), ensuring that it won't be accessed again when the client quits. Note that the assignment tpn->client = NULL; is superfluous since the XvdiDestroyVideoNotify function will do this anyway. But it's left for clarity and to match a similar invocation in XvdiSelectPortNotify. CVE-2022-46342, ZDI-CAN 19400 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit b79f32b57cc0c1186b2899bce7cf89f7b325161b)
2022-12-14Xi: disallow passive grabs with a detail > 255Peter Hutterer1-8/+14
The XKB protocol effectively prevents us from ever using keycodes above 255. For buttons it's theoretically possible but realistically too niche to worry about. For all other passive grabs, the detail must be zero anyway. This fixes an OOB write: ProcXIPassiveUngrabDevice() calls DeletePassiveGrabFromList with a temporary grab struct which contains tempGrab->detail.exact = stuff->detail. For matching existing grabs, DeleteDetailFromMask is called with the stuff->detail value. This function creates a new mask with the one bit representing stuff->detail cleared. However, the array size for the new mask is 8 * sizeof(CARD32) bits, thus any detail above 255 results in an OOB array write. CVE-2022-46341, ZDI-CAN 19381 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 51eb63b0ee1509c6c6b8922b0e4aa037faa6f78b)
2022-12-14Xtest: disallow GenericEvents in XTestSwapFakeInputPeter Hutterer1-2/+3
XTestSwapFakeInput assumes all events in this request are sizeof(xEvent) and iterates through these in 32-byte increments. However, a GenericEvent may be of arbitrary length longer than 32 bytes, so any GenericEvent in this list would result in subsequent events to be misparsed. Additional, the swapped event is written into a stack-allocated struct xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes, swapping the event may thus smash the stack like an avocado on toast. Catch this case early and return BadValue for any GenericEvent. Which is what would happen in unswapped setups anyway since XTest doesn't support GenericEvent. CVE-2022-46340, ZDI-CAN 19265 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63)
2022-11-02Bump version to 22.1.5xwayland-22.1.5Olivier Fourdan1-1/+1
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2022-11-02xwayland/input: Do not ignore leave eventsOlivier Fourdan1-3/+0
Commit 8a5f3ddb2 ("set tag on our surface") introduced the use of tags to differentiate our own surfaces, and commit a1d14aa8c ("Clear the "xwl-window" tag on unrealize") removed the tags before the surfaces are actually destroyed. Xwayland would then rely on these tags on the surface to decide whether to ignore or to process the Wayland event in various places. However, in doing so, it also checked for the tag on keyboard leave events. As a result, if the keyboard leave events is received after the X11 window is unrealized, keyboard_handle_leave() would not queue the LeaveNotify events for the DIX to proceed, and the key repeat would kick in and repeat the key event indefinitely. To avoid the issue, process events regardless of the tag as before in keyboard_handle_leave(). Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Fixes: 8a5f3ddb2 - "xwayland: set tag on our surface" Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1395 Tested-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com> Tested-by: Stefan Dirsch <sndirsch@suse.de> Acked-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 459e2855730a30bb50f4836f2ff6153841bf843c)
2022-10-28Revert "xwayland: Aggregate scroll axis events to fix kinetic scrolling"Olivier Fourdan2-75/+51
This reverts commit 2db46363542bfd0f62f20f5a898fef07424ffccc. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1392
2022-10-20Bump version to 22.1.4xwayland-22.1.4Olivier Fourdan1-1/+1
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2022-10-19xwayland: Clear the "xwl-window" tag on unrealizeOlivier Fourdan1-3/+13
Now that we keep the Wayland surface around for longer than the xwl_window, we might get events for that surface after the X11 window is unrealized. Make sure we untag the Wayland surface when the Wayland surface is delayed, to break the wl_surface/xwl_window relationship, so that events for that surface are discarded by Xwayland. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Fixes: e37f18ee9 - xwayland: Delay wl_surface destruction (cherry picked from commit a1d14aa8c5afbae2f99aa68454d429aed5852b72)
2022-10-19xwayland: set tag on our surfacesOlivier Fourdan3-0/+37
That allows to differentiate Xwayland's own surfaces from others. This is preparation work for optional libdecor support. v2: Check for surface not being NULL (Jonas Ådahl <jadahl@gmail.com>) Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 8a5f3ddb2e4232cbf47bdce25d4b4a929e80e2c9)
2022-10-19build: Bump wayland requirement to 1.18Olivier Fourdan1-1/+1
Xwayland uses API such as wl_proxy_set_tag()/wl_proxy_get_tag() which appeared in Wayland 1.18, but the build system still requires Wayland 1.5 at least. Bump the Wayland version to match the requirements. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 395c25f18520a6d2e3895f59b9e2feaf97ff7635)
2022-10-19Forbid server grabs by non-WM on *rootless* XWaylandDemi Marie Obenour1-1/+1
a77d95af61c09c91927d1aa4b9860b728b357cdb intended to do this, but the check for “is this rootless or rootful XWayland” was inverted. Fixes: a77d95af61c0 ("xwayland: Prevent Xserver grabs with rootless") Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit cb33e0d27892b885b0d86b5f99af2b71f660de56)
2022-10-03xwayland: Delay wl_surface destructionOlivier Fourdan4-1/+70
X11 and Wayland requests are unordered, causing a race in the X11 window and wl_surface association. To mitigate that race, delay the wl_surface destruction by 1 second, so that the compositor has time to establish the association before the wl_surface is destroyed: to see both the wl_surface created and the WL_SURFACE_ID X11 property set. This is only a mitigation though, a more robust solution requires a future dedicated Wayland protocol. v2: Clean up pending wl_surface destroy on exit as well. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1157 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Joshua Ashton <joshua@froggi.es> Tested-by: Sterophonick <sterophonick@gmail.com> See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/163 (cherry picked from commit e37f18ee97aa4856108ef701628e013d6bf4903e)
2022-09-14xwayland: Prevent Xserver grabs with rootlessOlivier Fourdan2-0/+52
Because of the design of most Wayland compositors, where the compositor is both a Wayland server and an X11 window manager, any X11 client issuing a server grab (i.e. XGrabServer()) can possibly hang the whole desktop when Xwayland is running rootless. This can happen with e.g. ImageMagick's import command with mutter. 1. "import" is launched and issues an XServerGrab(), 2. Xwayland restricts access to that "import" X11 client alone, 3. mutter continues to process events until it needs to sync with Xwayland (there's variability in time before the hang occurs), 4. When mutter does an XSync() (explicitly or implicitly through some other Xlib call), it will stop waiting for Xwayland to reply, 5. Xwayland waits for the XServerGrab() to be released by import, 6. "import" waits for a user input to release the XServerGrab(), 7. mutter is stuck waiting on Xwayland and does not process input events... To prevent this, re-route the GrabServer/UngrabServer requests and pretend the grab works but actually does nothing at all for all clients but the X11 window manager (which can still issue X11 server grabs, at its own risks). Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Closes: https://bugzilla.redhat.com/1914021 (cherry picked from commit a77d95af61c09c91927d1aa4b9860b728b357cdb)
2022-09-14dix: Skip more code in SetRootClip for ROOT_CLIP_INPUT_ONLYMichel Dänzer1-2/+2
Despite e957a2e5dd28 ("dix: Add hybrid full-size/empty-clip mode to SetRootClip"), I was still seeing all X11 client windows flashing when the root window size changes with rootless Xwayland (e.g. due to hotplugging a monitor). Skipping this code for ROOT_CLIP_INPUT_ONLY fixes the issue for me. (cherry picked from commit f778b56a742cf9df6641f2ec525120e859c74fa5)
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-30 07:55:52 +0000