- May 15, 2024
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1544>
-
- May 13, 2024
-
-
This fixes the scroll action in Steam Input in SteamOS/Gamescope when using the new libeis backend. Fixes: a1333342 ("xwayland: Add XTEST support using EIS") Signed-off-by:
Joshua Ashton <joshua@froggi.es> (cherry picked from commit 7745fde2) Part-of: <!1533>
-
- May 03, 2024
-
-
Olivier Fourdan authored
On DRM lease connector withdrawn event, Xwayland would free the corresponding xwl_output offered for lease. However, the pointer is still referenced from the rrLease->outputs[], meaning that trying to clean up the RANDR DRM leases as done with commit ef181265 (xwayland: Clean up drm lease when terminating) would cause a use after free and random crashes. To avoid that issue, on the connector withdraw event, set the connector withdrawn flag but do not to remove (i.e. free) the xwayland output if its is offered for lease. Then, once the lease is terminated, check for the xwl_outputs with a withdrawn connector and remove them (once we have no use for them anymore. Note that we cannot do that cleanup from xwl_randr_terminate_lease() as removing the xwl_output will free the RRcrtc resources, which checks for leases in XRANDR, and calls RRTerminateLease(), which chains back to xwl_randr_terminate_lease(). v2: Use a "withdrawn_connector" flag to mark outputs to remove (Xaver) Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Xaver Hugl <xaver.hugl@kde.org> fixes: ef181265 - xwayland: Clean up drm lease when terminating See-also: #946 See-also: !1130 (cherry picked from commit 40537824) Part-of: <!1515>
-
Olivier Fourdan authored
In xwl_randr_request_lease(), the code checks first for leased device, and then checks for existing output for lease. The former assumes there are outputs for lease whereas the latter checks for the output, connector and lease. So if there is any existing rrLease->outputs[]->devPrivate unset, the code would crash on a NULL pointer dereference on the first sanity check before having a chance to reach the second check that would have caught the problem. Invert the sanity checks so that we would catch this first and return a BadValue instead of possibly segfaulting. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Xaver Hugl <xaver.hugl@kde.org> (cherry picked from commit 21916ae1) Part-of: <!1515>
-
Fixes leak: ==15672== 60 bytes in 1 blocks are definitely lost in loss record 3,803 of 8,127 ==15672== at 0x4840718: malloc (vg_replace_malloc.c:392) ==15672== by 0x2F2698: XNFreallocarray (alloc.c:55) ==15672== by 0x1ADAA9: xwl_dmabuf_get_formats_for_device (xwayland-dmabuf.c:207) ==15672== by 0x1ADAA9: xwl_glamor_get_formats (xwayland-dmabuf.c:248) ==15672== by 0x303D86: cache_formats_and_modifiers (dri3_screen.c:176) ==15672== by 0x303D86: dri3_get_supported_modifiers (dri3_screen.c:229) ==15672== by 0x30331A: proc_dri3_get_supported_modifiers (dri3_request.c:389) ==15672== by 0x217B6B: Dispatch (dispatch.c:550) ==15672== by 0x21B9A0: dix_main (main.c:276) ==15672== by 0x51086C9: (below main) (libc_start_call_main.h:58) Fixes: a42992a4 ("dri3: rework format/modifier caching") (cherry picked from commit 3b6b88c1) Part-of: <!1515>
-
xwl_dmabuf_feedback_tranche_target_device always allocates a new drmDevice for xwl_feedback->tmp_tranche.drm_dev, so the pointers are never equal here. Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices") v2: * Flip order of checks, so drmDevicesEqual is called only if the supports_scanout flags match. (cherry picked from commit 4dc7e998) Part-of: <!1515>
-
Fixes leaks: ==13712== 144 bytes in 1 blocks are definitely lost in loss record 4,827 of 7,462 ==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340) ==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072) ==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104) ==13712== by 0x49BFAC9: process_device (xf86drm.c:4508) ==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670) ==13712== by 0x1AD370: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477) ==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104) ==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673) ==13712== by 0x53BFEE2: ffi_call (ffi64.c:710) ==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025) ==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631) ==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777) ==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019) ==13712== by 0x49AAB5E: wl_display_roundtrip_queue (wayland-client.c:1403) ==13712== 576 bytes in 4 blocks are definitely lost in loss record 6,289 of 7,462 ==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340) ==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072) ==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104) ==13712== by 0x49BFAC9: process_device (xf86drm.c:4508) ==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670) ==13712== by 0x1AD583: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477) ==13712== by 0x1AD583: xwl_window_dmabuf_feedback_main_device (xwayland-dmabuf.c:691) ==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104) ==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673) ==13712== by 0x53BFEE2: ffi_call (ffi64.c:710) ==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025) ==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631) ==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777) ==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019) ==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:566) ==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:553) Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices") (cherry picked from commit 82d3b8ff) Part-of: <!1515>
-
- Apr 17, 2024
-
-
these m4 macros had been used for autotools-based build system. But since this had been replaced by meson, these files are obsolete now. Fixes: c97397dc Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net> (cherry picked from commit 887fc712) Part-of: <!1493>
-
Olivier Fourdan authored
There are a number of regressions and hard to reproduce issues that find their roots in this change, so revert it until those can be ironed out some more. This reverts commit 4bb1f976. Closes: #1655 Closes: #1656 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit a65bb848) Part-of: <!1488>
-
- Apr 09, 2024
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1480>
-
Olivier Fourdan authored
ProcRenderAddGlyphs() adds the glyph to the glyphset using AddGlyph() and then frees it using FreeGlyph() to decrease the reference count, after AddGlyph() has increased it. AddGlyph() however may chose to reuse an existing glyph if it's already in the glyphSet, and free the glyph that was given, in which case the caller function, ProcRenderAddGlyphs() will call FreeGlyph() on an already freed glyph, as reported by ASan: READ of size 4 thread T0 #0 in FreeGlyph xserver/render/glyph.c:252 #1 in ProcRenderAddGlyphs xserver/render/render.c:1174 #2 in Dispatch xserver/dix/dispatch.c:546 #3 in dix_main xserver/dix/main.c:271 #4 in main xserver/dix/stubmain.c:34 #5 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #6 in __libc_start_main_impl ../csu/libc-start.c:360 #7 (/usr/bin/Xwayland+0x44fe4) Address is located 0 bytes inside of 64-byte region freed by thread T0 here: #0 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52 #1 in _dixFreeObjectWithPrivates xserver/dix/privates.c:538 #2 in AddGlyph xserver/render/glyph.c:295 #3 in ProcRenderAddGlyphs xserver/render/render.c:1173 #4 in Dispatch xserver/dix/dispatch.c:546 #5 in dix_main xserver/dix/main.c:271 #6 in main xserver/dix/stubmain.c:34 #7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: #0 in __interceptor_malloc libsanitizer/asan/asan_malloc_linux.cpp:69 #1 in AllocateGlyph xserver/render/glyph.c:355 #2 in ProcRenderAddGlyphs xserver/render/render.c:1085 #3 in Dispatch xserver/dix/dispatch.c:546 #4 in dix_main xserver/dix/main.c:271 #5 in main xserver/dix/stubmain.c:34 #6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-use-after-free xserver/render/glyph.c:252 in FreeGlyph To avoid that, make sure not to free the given glyph in AddGlyph(). v2: Simplify the test using the boolean returned from AddGlyph() (Michel) v3: Simplify even more by not freeing the glyph in AddGlyph() (Peter) Fixes: bdca6c3d - render: fix refcounting of glyphs during ProcRenderAddGlyphs Closes: xorg/xserver#1659 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 337d8d48) Part-of: <xorg/xserver!1478>
-
- Apr 04, 2024
-
-
And other 32-bit architectures, where uint32_t and CARD32 are not the same type. Otherwise the build will fail with GCC 14 with errors like: ../hw/xwayland/xwayland-glamor.c: In function ‘xwl_glamor_get_formats’: ../hw/xwayland/xwayland-glamor.c:291:43: error: passing argument 3 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types] 291 | num_formats, formats); | ^~~~~~~~~~~ | | | CARD32 * {aka long unsigned int *} ../hw/xwayland/xwayland-glamor.c:238:38: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’} 238 | uint32_t *num_formats, uint32_t **formats) | ~~~~~~~~~~^~~~~~~~~~~ ../hw/xwayland/xwayland-glamor.c:291:56: error: passing argument 4 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types] 291 | num_formats, formats); | ^~~~~~~ | | | CARD32 ** {aka long unsigned int **} ../hw/xwayland/xwayland-glamor.c:238:62: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’} 238 | uint32_t *num_formats, uint32_t **formats) | ~~~~~~~~~~~^~~~~~~ ../hw/xwayland/xwayland-glamor.c:295:28: error: passing argument 3 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types] 295 | num_formats, formats); | ^~~~~~~~~~~ | | | CARD32 * {aka long unsigned int *} ../hw/xwayland/xwayland-glamor.c:217:26: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’} 217 | uint32_t *num_formats, uint32_t **formats) | ~~~~~~~~~~^~~~~~~~~~~ ../hw/xwayland/xwayland-glamor.c:295:41: error: passing argument 4 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types] 295 | num_formats, formats); | ^~~~~~~ | | | CARD32 ** {aka long unsigned int **} ../hw/xwayland/xwayland-glamor.c:217:50: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’} 217 | uint32_t *num_formats, uint32_t **formats) | ~~~~~~~~~~~^~~~~~~ (cherry picked from commit f0a187f5) Part-of: <xorg/xserver!1470>
-
- Apr 03, 2024
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1465>
-
Previously, AllocateGlyph would return a new glyph with refcount=0 and a re-used glyph would end up not changing the refcount at all. The resulting glyph_new array would thus have multiple entries pointing to the same non-refcounted glyphs. AddGlyph may free a glyph, resulting in a UAF when the same glyph pointer is then later used. Fix this by returning a refcount of 1 for a new glyph and always incrementing the refcount for a re-used glyph, followed by dropping that refcount back down again when we're done with it. CVE-2024-31083, ZDI-CAN-22880 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (backported from commit bdca6c3d) Part-of: <xorg/xserver!1464>
-
Alan Coopersmith authored
CVE-2024-31081 Fixes: d220d690 ("Xi: add GrabButton and GrabKeysym code.") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 3e77295f) Part-of: <xorg/xserver!1464>
-
Alan Coopersmith authored
CVE-2024-31080 Reported-by: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762 Fixes: 53e821ab ("Xi: add request processing for XIGetSelectedEvents.") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 96798fc1) Part-of: <xorg/xserver!1464>
-
- Apr 02, 2024
-
-
Fixes 219c54b8 (cherry picked from commit 133e0d65) Part-of: <xorg/xserver!1452>
-
- Feb 08, 2024
-
-
X11 clients tend to assume that pointers have buttons. This assumption means they often fail to handle the X error that is generated when querying the button mapping of a pointer device that lacks buttons. This failure to handle the X error leads to those client applications to abruptly exit. This commit assigns vestigial buttons to the gesture pointer device for the sole purpose of backward compatibility with legacy X11 clients. That technique is already employed for a different pointer, the relative pointer device, for similar reasons, so this just makes the legacy client compatibility more complete. See https://gitlab.gnome.org/GNOME/mutter/-/issues/2353 (cherry picked from commit 456b0e86)
-
- Jan 16, 2024
-
-
José Expósito authored
Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
The cursor in DIX is actually split in two parts, the cursor itself and the cursor bits, each with their own devPrivates. The cursor itself includes the cursor bits, meaning that the cursor bits devPrivates in within structure of the cursor. Both Xephyr and Xwayland were using the private key for the cursor bits to store the data for the cursor, and when using XSELINUX which comes with its own special devPrivates, the data stored in that cursor bits' devPrivates would interfere with the XSELINUX devPrivates data and the SELINUX security ID would point to some other unrelated data, causing a crash in the XSELINUX code when trying to (re)use the security ID. CVE-2024-0409 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 2ef0f111)
-
The XSELINUX code will label resources at creation by checking the access mode. When the access mode is DixCreateAccess, it will call the function to label the new resource SELinuxLabelResource(). However, GLX buffers do not go through the XACE hooks when created, hence leaving the resource actually unlabeled. When, later, the client tries to create another resource using that drawable (like a GC for example), the XSELINUX code would try to use the security ID of that object which has never been labeled, get a NULL pointer and crash when checking whether the requested permissions are granted for subject security ID. To avoid the issue, make sure to call the XACE hooks when creating the GLX buffers. Credit goes to Donn Seeley <donn@xmission.com> for providing the patch. CVE-2024-0408 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Acked-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit e5e8586a)
-
Disabling a master device floats all slave devices but we didn't do this to already-disabled slave devices. As a result those devices kept their reference to the master device resulting in access to already freed memory if the master device was removed before the corresponding slave device. And to match this behavior, also forcibly reset that pointer during CloseDownDevices(). Related to CVE-2024-21886, ZDI-CAN-22840 (cherry picked from commit 26769aa7)
-
The `DisableDevice()` function is called whenever an enabled device is disabled and it moves the device from the `inputInfo.devices` linked list to the `inputInfo.off_devices` linked list. However, its link/unlink operation has an issue during the recursive call to `DisableDevice()` due to the `prev` pointer pointing to a removed device. This issue leads to a length mismatch between the total number of devices and the number of device in the list, leading to a heap overflow and, possibly, to local privilege escalation. Simplify the code that checked whether the device passed to `DisableDevice()` was in `inputInfo.devices` or not and find the previous device after the recursion. CVE-2024-21886, ZDI-CAN-22840 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit bc1fdbe4)
-
The `XISendDeviceHierarchyEvent()` function allocates space to store up to `MAXDEVICES` (256) `xXIHierarchyInfo` structures in `info`. If a device with a given ID was removed and a new device with the same ID added both in the same operation, the single device ID will lead to two info structures being written to `info`. Since this case can occur for every device ID at once, a total of two times `MAXDEVICES` info structures might be written to the allocation. To avoid it, once one add/remove master is processed, send out the device hierarchy event for the current state and continue. That event thus only ever has exactly one of either added/removed in it (and optionally slave attached/detached). CVE-2024-21885, ZDI-CAN-22744 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit 4a5e9b18)
-
There's a racy sequence where a master device may copy the button class from the slave, without ever initializing numButtons. This leads to a device with zero buttons but a button class which is invalid. Let's copy the numButtons value from the source - by definition if we don't have a button class yet we do not have any other slave devices with more than this number of buttons anyway. CVE-2024-0229, ZDI-CAN-22678 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit df3c6570)
-
The previous code only made sense if one considers buttons and keys to be mutually exclusive on a device. That is not necessarily true, causing a number of issues. This function allocates and fills in the number of xEvents we need to send the device state down the wire. This is split across multiple 32-byte devices including one deviceStateNotify event and optional deviceKeyStateNotify, deviceButtonStateNotify and (possibly multiple) deviceValuator events. The previous behavior would instead compose a sequence of [state, buttonstate, state, keystate, valuator...]. This is not protocol correct, and on top of that made the code extremely convoluted. Fix this by streamlining: add both button and key into the deviceStateNotify and then append the key state and button state, followed by the valuators. Finally, the deviceValuator events contain up to 6 valuators per event but we only ever sent through 3 at a time. Let's double that troughput. CVE-2024-0229, ZDI-CAN-22678 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit 219c54b8)
-
If a device has both a button class and a key class and numButtons is zero, we can get an OOB write due to event under-allocation. This function seems to assume a device has either keys or buttons, not both. It has two virtually identical code paths, both of which assume they're applying to the first event in the sequence. A device with both a key and button class triggered a logic bug - only one xEvent was allocated but the deviceStateNotify pointer was pushed on once per type. So effectively this logic code: int count = 1; if (button && nbuttons > 32) count++; if (key && nbuttons > 0) count++; if (key && nkeys > 32) count++; // this is basically always true // count is at 2 for our keys + zero button device ev = alloc(count * sizeof(xEvent)); FixDeviceStateNotify(ev); if (button) FixDeviceStateNotify(ev++); if (key) FixDeviceStateNotify(ev++); // santa drops into the wrong chimney here If the device has more than 3 valuators, the OOB is pushed back - we're off by one so it will happen when the last deviceValuator event is written instead. Fix this by allocating the maximum number of events we may allocate. Note that the current behavior is not protocol-correct anyway, this patch fixes only the allocation issue. Note that this issue does not trigger if the device has at least one button. While the server does not prevent a button class with zero buttons, it is very unlikely. CVE-2024-0229, ZDI-CAN-22678 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit ece23be8)
-
Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Since buttons can be arbitrarily mapped to anything up to 255 make sure we have enough bits for the maximum mapping. CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit 9e2ecb2a)
-
- Jan 11, 2024
-
-
For ALUs which may leave the alpha channel at values other than 1.0. Closes: xorg/xserver#1615 v2: * List safe ALUs instead of unsafe ones (cherry picked from commit e5a3f3e8)
-
Preparation for the following commit, no functional change intended. (cherry picked from commit 8f66c156)
-
It caused an incorrect result of the blend operation. Use glColorMask to prevent non-1.0 alpha channel values in a depth 32 pixmap backing an effective depth 24 window. For blending operations, the expectation is that the destination drawable contains valid pixel values, so the alpha channel should already be 1.0. Fixes: d1f14289 ("glamor: Ignore destination alpha as necessary for composite operation") Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3104 (cherry picked from commit d1bbf82d)
-
XTest requests lets the client specify a device ID, only if none is specified do we fall back to the XTEST special device. As of commit aa407425 input: Add new hook DeviceSendEventsProc for XTEST regular devices are no longer able to send XTest events because they have no sendEventsProc set. This caused issue #1574 and the crash was fixed with commit e820030d xtest: Check whether there is a sendEventsProc to call but we still cannot send XTest events through a specific device. Fix this by defaulting every device to the XTest send function and punting it to the DDX (i.e. Xwayland) to override the devices as necessary. Fixes e820030d Fixes aa407425 (cherry picked from commit de0031ee)
-
Otherwise only XTest events on the XTest device get handled, XTest requests on real devices are still processed as normal events. (cherry picked from commit 7f7adfde)
-
This just makes the existing behavior explicit, previously we relied on a malloc(numAxes * ...) to return NULL to error out. (cherry picked from commit 7aba2514)
-
If we remove a master device and specify which other master devices attached slaves should be returned to, enforce that those two are indeeed a pointer and a keyboard. Otherwise we can try to attach the keyboards to pointers and vice versa, leading to possible crashes later. (cherry picked from commit 37539cb0)
-
Olivier Fourdan authored
Xwayland uses OEFFIS_DEVICE_ALL_DEVICES to get all possible device types enabled. Be more selective and specify explicitly keyboard and pointer instead of relying on what "all devices" translates to in the stack. See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3194 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 1bf4d60a)
-
(cherry picked from commit 5c8f70a1)
-
LOCAL_PEERCRED is similar to SO_PEERCRED but takes SOL_LOCAL. On DragonFly cr_pid isn't supported yet, so fall back to getpeereid(). Based on wayland/wayland@54b237a6 (cherry picked from commit 58e8c967)
-
- Dec 13, 2023
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-