In commit b320ca0f the mask was inadvertently changed from octal 0177 to
hexadecimal 0x177.

Fixes commit b320ca0f


  Xtest: disallow GenericEvents in XTestSwapFakeInput

Found by Stuart Cassoff

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit bb1711b7)

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 ccdd431c)

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 8f454b79)

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 b8a84cb0)

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 842ca3cc)

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 b79f32b5)

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 51eb63b0)

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 b320ca0f)

Michel Dänzer authored Mar 15, 2022 and Olivier Fourdan committed Jul 20, 2022

Even if there's no pending frame callback yet.

Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.

Doing this requires some adjustments elsewhere:

1. xwl_present_reset_timer needs to check for a pending frame callback
   as well.
2. xwl_window_create_frame_callback needs to call
   xwl_present_reset_timer for all child windows hooked up to
   frame_callback_list, to make sure the timer length takes the pending
   frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
   before calling xwl_window_create_frame_callback, for 2. to work.

Closes: #1309
Fixes: 9b31358c

 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 9e5a3796)

Peter Hutterer authored Jul 05, 2022 and Olivier Fourdan committed Jul 12, 2022

No validation of the various fields on that report were done, so a
malicious client could send a short request that claims it had N
sections, or rows, or keys, and the server would process the request for
N sections, running out of bounds of the actual request data.

Fix this by adding size checks to ensure our data is valid.

ZDI-CAN 16062, CVE-2022-2319.

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 6907b6ea)

Peter Hutterer authored Jul 05, 2022 and Olivier Fourdan committed Jul 12, 2022

XKB often uses a FooCheck and Foo function pair, the former is supposed
to check all values in the request and error out on BadLength,
BadValue, etc. The latter is then called once we're confident the values
are good (they may still fail on an individual device, but that's a
different topic).

In the case of XkbSetDeviceInfo, those functions were incorrectly
named, with XkbSetDeviceInfo ending up as the checker function and
XkbSetDeviceInfoCheck as the setter function. As a result, the setter
function was called before the checker function, accessing request
data and modifying device state before we ensured that the data is
valid.

In particular, the setter function relied on values being already
byte-swapped. This in turn could lead to potential OOB memory access.

Fix this by correctly naming the functions and moving the length checks
over to the checker function. These were added in 87c64fc5 to the
wrong function, probably due to the incorrect naming.

Fixes ZDI-CAN 16070, CVE-2022-2320.

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Introduced in c06e27b2



Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit dd8caf39)

Peter Hutterer authored Jul 05, 2022 and Olivier Fourdan committed Jul 12, 2022

Most similar loops here use a pointer that advances with each loop
iteration, let's do the same here for consistency.

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit f1070c01)

Michel Dänzer authored Mar 14, 2022 and Olivier Fourdan committed Mar 15, 2022

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 (dispatch.c:3546)
  Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
    at 0x48470E4: free (vg_replace_malloc.c:872)
    by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
    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)
    by 0x5E27EE: ClientReady (connection.c:599)
    by 0x5E6CB7: ospoll_wait (ospoll.c:657)
    by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
  Block was alloc'd at
    at 0x4849464: calloc (vg_replace_malloc.c:1328)
    by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
    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)
    by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
    by 0x4F36EC: RealizeTree (window.c:2606)
    by 0x4F39F5: MapWindow (window.c:2683)

Fixes: 288ec0e0

 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 102764b6)

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)

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: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 47d33174)

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: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 6ad6517a)

Michel Dänzer authored Dec 24, 2021 and Olivier Fourdan committed Feb 11, 2022

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: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman <jaapbuurman@gmail.com>
(cherry picked from commit 288ec0e0)

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Povilas Kanapickas authored Dec 14, 2021 and Olivier Fourdan committed Dec 14, 2021

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)

Povilas Kanapickas authored Dec 14, 2021 and Olivier Fourdan committed Dec 14, 2021

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: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 6c4c5301)

Povilas Kanapickas authored Dec 14, 2021 and Olivier Fourdan committed Dec 14, 2021

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: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit b5196750)

Povilas Kanapickas authored Dec 14, 2021 and Olivier Fourdan committed Dec 14, 2021

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: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit e56f61c7)

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 <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 6dd9709b)

Add (verbose) statements to trace the actual backend used with glamor.

That can be useful for debugging.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit c5d1fed9)

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: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
(cherry picked from commit 30d0d4a1)

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: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
(cherry picked from commit 96c82bef)

Michel Dänzer authored Nov 01, 2021 and Ernst Sjöstrand committed Nov 17, 2021

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: Olivier Fourdan <ofourdan@redhat.com>


(cherry picked from commit b656b0aa)

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Xwayland 21.1.3 release candidate 1.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

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)

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)

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)

James Jones authored Mar 26, 2021 and Olivier Fourdan committed Oct 18, 2021

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)

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)

Povilas Kanapickas authored Sep 06, 2021 and Olivier Fourdan committed Oct 18, 2021

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)

Simon Ser authored Jul 05, 2021 and Olivier Fourdan committed Oct 18, 2021

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)

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)

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)

Michel Dänzer authored Jun 30, 2021 and Michel Dänzer committed Jun 30, 2021

    
Xwayland 21.1.2 release candidate 1.