This works as intended — the (fake) front buffer needs to be added
only if the client didn't request it in the first place — even if the
client requests the same attachment multiple times. This ensures we
never try to access more than (count + 1) entries of the buffers array.
Fixes: ff6c7764c2 ("DRI2: Implement protocol for DRI2GetBuffersWithFormat")
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When the target device is disabled, ProcXIGrabDevice returns
AlreadyGrabbed directly as the request handler return value.
AlreadyGrabbed (1) is a grab status code, not an X error code. The
server dispatch loop interprets any non-zero return value as an X
protocol error, so the client receives BadRequest (error code 1)
instead of a proper XIGrabDevice reply with status=AlreadyGrabbed.
And use XIAlreadyGrabbed since this is an XI2 request. It's the same
value anyway.
This is the same class of bug that was fixed in ProcXIPassiveGrabDevice
by commit 'Xi: Fix XIPassiveGrab handling of keycodes > 255'
Fix by jumping to the reply path with status=AlreadyGrabbed instead of
returning the status code directly.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2186>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XLibre 10-nvidia.conf is extended w.r.t. XOrg version and can be overwritten by
NVidia installers or packages, hence it is safer to split it into 10-nvidia.conf
(a common part) and 10-nvidia-modules.conf (an extra part).
This patch also provides /etc/X11/xorg.conf.d/10-nvidia.conf.debian and
/etc/X11/xorg.conf.d/10-nvidia-modules.conf.debian files that, when .debian
suffix is removed, shadow the respective files in /usr/share/X11/xorg.conf.d
and set Debian specific search directories for drivers and modules.
Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Moved the cursor glyph cropping into a separate function that handles reflections and rotations.
Also, x/y are indexes into the buffer, so they should be clamped to width/height len - 1 for correctness.
Signed-off-by: John Studnicka <contact@zentec.dev>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On allocation error, also have to remove devices and possibly
clear out some other pointers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Finally, after 33 years something deals with the allocation failure. Put
on a party hat!
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This code has failed for decades by triggering a segfault, let's not
bother figuring out the perfect cleanup path.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The sequenceNumber and length fields are already swapped behind the scenes
by X_SEND_REPLY*() macros, so we must not swap them here a second time.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The recent development versions of xorgxrdp require these 5 glamor_*
functions that were made private in the past:
glamor_fds_from_pixmap: Made private in ea232c7
glamor_pixmap_from_fds: Made private in 81c1479
glamor_get_formats: Made private in 6f6aab8
glamor_get_modifiers: Made private in 0644764
glamor_get_drawable_modifiers: Made private in 800ab10
Exporting them again to make xorgxrdp compilable with XLibre.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Structs that are sent to the client may leak data via unititialized
padding bytes. Let's not do that.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2185>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Unlikely that those operations ever coming from a remote client,
let alone one with different endianess, but nevertheless let's be
correct here :)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The individual spec entries' fields also need to be swapped.
Each is made of two CARD32's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In the multiwindow WM, we need to cancel the X input focus if the
Windows input focus has gone to the desktop, or another application's
window.
We could maybe avoid some unneeded work by not doing this if the
WM_KILLFOCUS wParam is another window owned by us, which is immediately
going to be given the X input focus.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The previous change is not enough, as WM_KILLFOCUS can apparently be
sent to the window losing focus after WM_ACTIVATE has been sent to
the window gaining focus.
Try using WM_SETFOCUS instead, as that has the correct ordering and seems
more logical.
The test "!pWin || !pWin->overrideRedirect" is confusingly written: It's
true if:
(a) pWin is NULL (= X window doesn't exist, shouldn't happen), or
(b) pWin->overrideRedirect is FALSE
i.e. the intended effect is "don't give focus to override redirect windows"
There seem to be some cases where this still isn't quite correct: A
reproduction isn't known, but it seems to be related to minimizing a
maximized Windows window, and having window activation move to a
maximized X window beneath it.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
