This was fixed in commit 51eb63b0ee but woefully badly. Instead of returning
XIAlreadyGrabbed via the Reply, it simply returned the value from the
request handler - causing the server to interpret it as BadRequest.
Fix it and do what we intended to do instead.
Fixes: 51eb63b0ee ("Xi: disallow passive grabs with a detail > 255")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2186>
Currently, when started fullscreen, Xwayland rootful would use a default
resolution of "640x480" and apply a viewport to match the actual output
resolution.
That's quite counter intuitive, because when started fullscreen, one
would expect the default Xwayland root size to match the logical size
of the output where it is placed, unless of course, a geometry is
explicitly specified from the command line.
Fix the default resolution to be driven from the window size instead,
even when started fullscreen, so that one can start Xwayland rootful
and fullscreen and get the optimal resolution by default.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2196>
Xwayland does not support indirect GLX contexts and enabling them will
crash the xserver.
Refuse to start if indirect GLX contexts are enabled on the command
line.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1745>
The design document hw/xfree86/doc/ddxDesign.xml states that:
| AddScreen() should only fail because of programming errors or
| failure to allocate resources (like memory).
| All configuration problems should be detected BEFORE this point.
Different command line options errors are detected in xwl_screen_init()
and can cause AddScreen() to fail, which is not compliant with the
specification.
Move all command line checks out of xwl_screen_init() in a separate
function that will take care of verifying the command line options and
bail out with meaningful error messages.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1745>
If we fail to set up the default rules our keymap is likely going to end
up messed up, which means the client/user can't work correctly anyway.
And if we're that low on memory that we can't allocate these rules,
we're about to fall over anyway so why bother.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
CHK_MASK_LEGAL expands to 'return BadValue' when the check fails and
doesn't clean up the already allocated names.keycodes, names.types, etc.
Move the check up so we don't need any cleanup code.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
Use the XNF version for this and simply bail out if it fails. Clearly
this hasn't been a problem in over 20 years and I can't be bothered
finding the perfect cleanup path.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
During extension init this makes sense, failing to assign a name to a
new device is more controversial but none of the paths handle
this situation correctly right now so we're just as likely to introduce
an exploit if the name remains NULL.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
Add a new commmand line option to enable the Xwayland
clipboard selection bridge when running in rootful mode.
By default, clipboard selection bridge is disabled to keep the default
of having Xwayland rootful running isolated from the rest of the
applications.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2139>
To implement selection bridges, we need to be able to set the
SelectionOwner from the Xserver code.
Rather than duplicating the dix code for ProcSetSelectionOwner(), move
the code to its own dixSetSelectionOwner() function, and hook that from
the existing ProcSetSelectionOwner().
With that, a DDX can set the selection owner as intended.
This is preparation work for the following commits, no functional change
intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2139>
This is intended to be used to implement selection bridges in mixed
windowing systems such as Xwayland.
This adds a new SelectionBridgeCallback along with a new
SelectionBridgeInfoRec to convey the information from a selection
request so that a DDX such as Xwayland can bridge that to some other
clipboard implementation from another windowing system directly from the
DDX.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Assisted-by: Cursor AI
Assisted-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2139>
Commit 34934c37d6 restored calling register_damage() in
xwl_realize_window() before ensure_surface_for_window().
However if register_damage() succeeds and ensure_surface_for_window()
returns NULL, it would exit without "unregistering" the damage hook.
The X11 window, however, may still get damages reports, in which case
xwl_window_from_window() would return NULL, causing a NULL pointer
dereference in damage_report().
To avoid the issue, make sure we unregister the damage report if
ensure_surface_for_window() has failed, and add an early exit in
damage_report() if xwl_window is NULL.
v2: unregister_damage() unconditionally if ensure_surface_for_window()
failed (Michel Dänzer)
Fixes: commit 34934c37d6 ("revert: register damage before ensure_surface_for_window")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1886
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2190>
SProcVidModeSwitchToMode() only byte-swapped the screen field (CARD32)
from the 52-byte xXF86VidModeSwitchToModeReq struct. All other fields
were passed to ProcVidModeSwitchToMode unswapped.
This implements full swapping, including the pre-v2 version because how
could we have lived without that for so long...
SwapRestL is not technically needed but added for consistency with other
request handlers.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The dispatch infrastructure already handles request length byte-swapping via
get_req_len() / client->req_len, so let's not double-swap the length
field back to the wrong byte order.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
Three GLX byte-swap dispatch functions advance the pc pointer past the
vendor private header (pc += __GLX_VENDPRIV_HDR_SIZE) for local field
swapping, then pass the ADVANCED pc to the non-swap handler. But the
non-swap handlers expect pc to point to the start of the
xGLXVendorPrivateReq — they cast pc to xGLXVendorPrivateReq* to access
req->contextTag, then do their own pc += __GLX_VENDPRIV_HDR_SIZE.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
SProcRenderSetPictureFilter() swapped the picture and nbytes fields but
did not swap the xFixed (CARD32) filter parameter values that follow the
filter name string in the request body.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
ProcShmCreateSegment() sent the xShmCreateSegmentReply to the client
without byte-swapping the sequenceNumber field for byte-swapped clients.
Every other SHM Proc function that sends a reply (ProcShmQueryVersion,
ProcShmGetImage) correctly swaps the reply fields.
The sequenceNumber is a CARD16 that Xlib/XCB uses to match replies to
their corresponding requests. With a garbled sequence number, the client
library will mismatch the reply with the wrong request, causing the
client to hang waiting for the real reply, process stale data from a
different request's reply, or crash due to unexpected reply format.
Fix by adding byte-swap of sequenceNumber and length before
WriteToClient, consistent with the other SHM reply handlers.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The CARD32 *value pointer was computed as (ptr + sizeof(rep))
BEFORE the NULL check for ptr. If AddFragment returns NULL, this
performs pointer arithmetic on a null pointer, which is undefined
behavior per C11 section 6.5.6 paragraph 8. With aggressive compiler
optimizations (e.g., GCC -O2 with LTO), the compiler could reason
that since ptr was used in arithmetic, it must be non-NULL, and
optimize away the NULL check entirely. This would then cause a
write to an invalid address on OOM.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The byte-swap check for rep.spec.client used 'client->swapped'
(the queried client) instead of 'sendClient->swapped' (the
requesting client). The reply is sent to sendClient, so swapping
must be based on sendClient's byte order. When a byte-swapped
client queries a native-byte-order client (or vice versa), the
spec.client field in the reply has the wrong byte order, causing
the client library to misinterpret the XID. Lines 504 and later
correctly use sendClient->swapped, so this was an oversight.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
SProcXResQueryClientIds() swapped the numSpecs field but did not swap
the individual xXResClientIdSpec entries that follow the request header.
Each spec contains two CARD32 fields: client (an XID) and mask (a
bitmask selecting which client ID types to query).
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
