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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/946
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1130
(cherry picked from commit 4053782443)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1515>
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 21916ae148)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: 6f0b9deed6 ("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 4dc7e99840)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: 6f0b9deed6 ("xwayland: use drmDevice to compare DRM devices")
(cherry picked from commit 82d3b8ff05)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1515>
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 f0a187f55d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1470>
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 456b0e86bb)
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 2ef0f1116c)
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 7f7adfdef8)
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 1bf4d60acd)
When creating the output with the default "XWAYLAND<n>" name, we use
the MAX_OUTPUT_NAME value to allocate a lot more memory than necessary
to accommodate for future output names once they get updated, but by
doing so, we also send XRandR way too much (zeroed) data since the
"nameLength" value is (purposely) set too big.
So, instead, let's just update the name after creating the RR output,
this way we set both the name and nameLength to their correct values
while keeping the initial large allocation.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
(cherry picked from commit 83453fb51e)
At creation, Xwayland uses a generic output name ("XWAYLAND0", etc.) for
the XRandR outputs, and later, once the name is known from the Wayland
protocols, updates the output names using the actual names from the
Wayland compositor.
However, when doing so, it simply updates the string, the "nameLength"
isn't updated, so the name passed to the clients might either end up
being truncated or contain portions of the previous (initial) output
name.
Note, this is using a fixed size buffer initialized with zeros, so this
cannot leak any data other than the previous output name, so this is
mainly a cosmetic issue.
Update the output's "nameLength" when updating the output name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
(cherry picked from commit 0e314afef6)
When running fullscreen, if an X11 client has changed the resolution,
Xwayland is using a viewport to emulate the expected resolution.
When changing focus, the Wayland compositor will send a configure event
with the actual surface size, not the size of the emulated XRandR
resolution.
As a result, changing focus while XRandR emulation (and hence the
viewport) is active in Xwayland will revert the resolution to the actual
output size, defeating the XRandR emulation.
To avoid that issue, only change the size when not running fullscreen.
Fixes: 53b6d4db7 - xwayland: Apply root toplevel configure dimensions
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit a797776ff2)
Whenever the output configuration changes, if Xwayland is running
fullscreen, we may need to update the viewport in use or even update the
output on which Xwayland is currently running fullscreen.
Add a new helper function xwl_window_rootful_update_fullscreen() that
will recompute the fullscreen state and the viewport setup so that the
fullscreen Xwayland rootful window matches the new setup.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit 73b9ff53c3)
Xwayland maintains a connection to EI up for 10 minutes after an X11
client has vanished, to avoid going through the connection phase every
time a short lived X11 client comes and goes.
However, if the EI client gets freed (through some other event, e.g. the
user decides to terminate the EI session), Xwayland would still keep the
callback alive and end up trying to free an already freed EI client:
Invalid read of size 4
at 0x4C5E6F9: object_unref (util-object.h:89)
by 0x4C5E6F9: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404)
by 0x5E63FF: DoTimer (WaitFor.c:276)
by 0x5E6463: DoTimers (WaitFor.c:290)
by 0x5E6164: check_timers (WaitFor.c:133)
by 0x5E61E9: WaitForSomething (WaitFor.c:195)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd
at 0x48452AC: free (vg_replace_malloc.c:974)
by 0x4C5E729: object_destroy (util-object.h:73)
by 0x4C5E729: object_unref (util-object.h:91)
by 0x4C5E729: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804)
by 0x5EA977: HandleNotifyFd (connection.c:809)
by 0x5EE8E3: ospoll_wait (ospoll.c:657)
by 0x5E624D: WaitForSomething (WaitFor.c:208)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Block was alloc'd at
at 0x484782C: calloc (vg_replace_malloc.c:1554)
by 0x4C5E777: ei_create (libei.c:73)
by 0x4C5E777: ei_create_context (libei.c:97)
by 0x42994B: setup_ei (xwayland-xtest.c:366)
by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658)
by 0x54ED4C: ProcXTestFakeInput (xtest.c:441)
by 0x54EE56: ProcXTestDispatch (xtest.c:475)
by 0x4AD6E6: Dispatch (dispatch.c:546)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
To avoid that issue, make sure to cancel the timer as soon as a EI
client is freed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
See-also: https://bugzilla.redhat.com/2243076
(cherry picked from commit 9617de733b)
If we fail to setup EI, give up on using EI for XTEST and restore the
default XTEST handlers.
This happens when neither the portal nor the socket backends are usable.
This does not affect the portal operation though, if the user choose not
to allow a particular client, Xwayland would continue to use EI.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
(cherry picked from commit 6b56ae68e5)
With EI support wired to XTEST, and oeffis being enabled unconditionally
means that Xwayland will always go through the XDG portal for XTEST when
supported.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Xwayland itself, as a regular Wayland client, has no way to tell that it
is running on a nested compositor.
So to keep backward compatibility with existing (and also common) use
cases such as nested compositors, best is to disable support for the XDG
portal by default, and add a new command line option "-enable-ei-portal"
for the Wayland compositors (who spawn Xwayland rootless) to explicitly
enable support for the input emulation XDG portal in Xwayland.
A Wayland compositor running nested should not use that command line
option with Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Fixes: a1333342 - xwayland: Add XTEST support using EIS
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
(cherry picked from commit cfcbb075c2)
Some drivers might not support explicit format modifiers. On these
drivers `gbm_bo_create_with_modifiers()` will fail and the
`gbm_bo_create()` code path will be used instead.
In this case, if the LINEAR modifier is advertised (and the INVALID
modifier is not) add the `GBM_BO_USE_LINEAR` flag.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1438
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito's avatarJosé Expósito <jexposit@redhat.com>
(cherry picked from commit 287638db59)
This can happen if the window has never completed a Present operation.
Fixes: 4230176080 ("xwayland/present: Embed present_vblank_rec in xwl_present_event")
(cherry picked from commit 32c5b2c044)
We specify a sensible default geometry for decorated rootful windows,
but not for undecorated ones. Make the default geometry apply to rootful
windows in general.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit 8128a21554)
While we now have support for resize of the root window through
libdecor, we still ignore toplevel configure dimensions when libdecor is
not in use. This ignores user intent in many Wayland servers, and some
xdg_toplevel states when active have strong requirements for adherence
to configure dimensions.
Resize in response to xdg_toplevel configure dimensions like we do for
libdecor configure events.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit 53b6d4db7e)
The upcoming handling of plain xdg_toplevel.configure events will need
to use the xwl_window resize helper. Move it outside XWL_HAS_LIBDECOR,
move the remaining dimension logic from handle_libdecor_configure into
it and update the name accordingly.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit 4f869c6eda)
When handling libdecor configure, we first update our xwl output and
screen if dimensions differ from the current xwl_screen, and then commit
a new libdecor frame which acknowledges the xdg_surface.configure event.
If the initial configure events contains non-zero dimensions, we will
update the xwl output before acknowledging the initial configure. As we
attach a buffer and commit the surface when updating the output, this
leads to a protocol error.
Instead, move the surface commit till the end of the configure handler
so it always happens after the ack.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
(cherry picked from commit 295fb71653)
Similar to commit 94deed272 - " xwayland: Use sensible defaults for
rootful size", mark fullscreen mode as fixed so that the actual monitor
layout is not reflected in the single fullscreen rootful window.
Without this, if "-fullscreen" is used without "-geometry", the XRandR
configuration is taken from the compositor via wl_output/xdg-output and
cannot be changed by the X11 clients.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 34446a9952)
Enforce sensible min/max values for the window size when using libdecor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 881e1a5693)
This is to avoid repeating the same code in two places.
This is essentially a cosmetic change, not a functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit f19fe9d260)
Allow passing an optional libdecor configuration pointer to
xwl_window_update_libdecor_size() so that we can reuse it from more than
one place and avoid duplicating that code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit c180eca8ef)
The configure handler in libdecor is triggered any time a new
configuration is received.
According to the documentation from libdecor, an application should
respond to that event by creating a suitable libdecor_state, and apply
it using libdecor_frame_commit().
So we ought to attach a new buffer matching the new size and commit
the Wayland surface.
The actual content of the window does not need to be explicitly
repainted, that occurs through the call to SetRootClip():
xwl_output_set_mode_fixed()
-> update_screen_size()
-> SetRootClip()
-> miHandleValidateExposures()
-> miWindowExposures()
-> miPaintWindow()
This fixes an issue with mutter where maximizing a window and then
switching to another window would sometimes resize the Xwayland window
back to its pre-maximized size, or with Weston where the Xwayland window
would initially show up black until the pointer moves to the window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 6d00c2bc10)
This moves the code which updates the XRandR modes and sets the root
window size to its own function.
This preparation work for the next commit, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit e37539e1e2)
The configure handler for libdecor, namely handle_libdecor_configure(),
is where both the content and the decorations get resized (when needed).
If for any reason, the actual size of the Xwayland screen fails to be
updated, we would still appy the expected size rather than the actual
one for the libdecor state.
To avoid this, use the actual xwl_screen width/height for the libdecor
state.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit cda004c2a9)
For libdecor, we will have to attach a new buffer and commit from two
different handlers (libdecor configure and commit).
Having xwl_window_attach_buffer() separate from xwl_window_post_damage()
is to allow for that.
This commit should not introduce any functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 8bbd908d1d)
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
Second attempt, after fixing a few regressions from the first attempt.
(cherry picked from commit 4bb1f976d5)
We're keeping it for unit tests, but we don't want to ship it from this
branch.
Also disable Xvfb in CI for ninja test. It's still built and used for
unit tests as part of ninja dist, but we don't want to run XTS on Xvfb.
(cherry picked from commit 0408fcb329)
If "-decorate" is used but no "-geometry" is specified, Xwayland rootful
would take its size from the actual Wayland outputs combined.
That is not practical, especially when using multiple outputs, as the
resulting Xwayland window would be much larger than a single monitor.
To avoid that, set a sensible default size for the Xwayland decorate
window, using 640x480 to match what Xephyr does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
libdecor support seems quite stable, no need to mark that experimental.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
By default, the Xwayland window in rootful mode was not resizable.
Make the Xwayland window resizable using libdecor in rootful mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is preparation work for making Xwayland rootful resizeable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
This will be needed with the next commit: If a child window completely
obscures a toplevel ancestor of different depth, the child window can
use page flipping only if the depth of the presented pixmap matches that
of the window's backing pixmap, or the former may contain pixel values
which are not suitable for the toplevel window's depth.
