CheckKeySyms() has two loops: the first processes keys in the SetMap
request range, the second fills in any missing keys from the existing
map.
The indexing between the two was inconsistent: the first loop
uses a zero-based index + req->firstKeySym, the second loop used it just
as zero-based index.
Example:
req->firstKeySym = 50
req->nKeySyms = 10
i goes from 0 to 10,
loop 1 checks [50, 60), changes the width but finishes with i at 10.
loop 2 then runs over [10, 255(, copying the old keymap width
The second loop overwrites the new widths with the width of the
existing keymap. The subsequent SetKeySyms worked on the new width
and may write fewer actions than the map width.
A subsequent XkbGetMap request would then read XkbKeyNumActions()
entries (derived from the new wider key_sym_map.width) from the shorter
action allocation, causing an out-of-bounds heap read. The overread
bytes would be copied into the GetMap reply and sent back to the client,
producing a bounded heap information disclosure.
This vulnerability was discovered by:
WONJOON HWANG (@joon1337) working with TrendAI Zero Day Initiative
ZDI-CAN-32408
CVE-2026-93524
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit cea71d0273)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fields in XkbClientMapRec and XkbServerMapRec that denote size/num
and are unsigned short can result in truncations. For example
when XkbResizeKeyType() computes the new size_syms value as
(nTotal * 15) / 10, the result may be implicitly truncated to 16
bits on assignment. This causes an undersized calloc allocation, and the
subsequent copy loop writes based on the actual (untruncated) key count,
resulting in a heap buffer overflow. A similar truncation may happen
in XkbResizeKeySyms() and XkbResizeKeyActions().
Widen the fields from unsigned short to unsigned int. These are internal
server structures, not wire protocol types.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31834
CVE-2026-93518
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 89101a6c66)
Commit a3171732d ("xkb: Always use MAP_LENGTH keymap size") converted
most XKB allocation functions to use MAP_LENGTH (256) instead of
max_key_code + 1. It also removed the per-array reallocarray() calls in
XkbChangeKeycodeRange(), replacing them with a memset up to MAP_LENGTH.
However, XkbAllocNames() was missed and still allocates names->keys to
max_key_code + 1.
When a keycodes component with max_key_code < 255 is loaded (e.g.
sun(type6) with max_key_code=132) and then a SetMap request extends
maxKeyCode to 255, XkbChangeKeycodeRange() memsets names->keys from
max_key_code to MAP_LENGTH-1, writing past the undersized allocation.
Fix by allocating names->keys to MAP_LENGTH, consistent with all other
keymap arrays after a3171732d.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31941
CVE-2026-93520
Fixes: a3171732da ("xkb: Always use MAP_LENGTH keymap size")
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit b941a473e0)
_CheckSetDoodad() allocates doodad->text.text via _GetCountedString()
and then attempts to allocate doodad->text.font. If the font string
allocation fails (e.g. because the font string length extends past
the request boundary), the error handler frees doodad->text.text but
does not NULL the pointer. The doodad was already added to the geometry
by XkbAddGeomDoodad() before the string allocations, so when
XkbFreeGeometry() runs cleanup, _XkbClearDoodad() frees the same
dangling pointer again, resulting in a double-free.
NULL the pointer after freeing it to prevent the double-free.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31221
CVE-2026-88812
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 0d1b1b0bad)
When a window is destroyed, present_clear_window_notifies()
does not remove the notify list node from the window. The notify
may then be freed as part of the window_priv, leaving dangling
pointers in place.
When the vblank owning the notify is later torn down,
present_free_window_notify() calls xorg_list_del() which
writes through these dangling pointers (use-after-free write).
This happens when Present cross-window notifies are used: a
PresentPixmap on window A can reference window B as a notify target.
An untriggered wait_fence keeps the vblank alive so that B can be
destroyed first, creating the dangling-pointer window.
Fix this by calling the free function we have (and moving the window
reset into that function too). present_clear_window_notifies is only
called from one place anyway.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31830
CVE-2026-93515
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 1b6955c310)
__glXDisp_RenderLarge() allocates the large command buffer based on
cmdlen (from hdr->length, the total command size embedded in the
payload), but copies dataBytes (from req->dataBytes, the payload size
of the current sub-request) into it. The existing length check only
validates that the X11 request length is consistent with dataBytes,
not that dataBytes fits within the cmdlen-sized buffer.
A malicious client can set hdr->length to a small value (e.g. 12 bytes)
while sending a large dataBytes (up to ~256KB or more with
BIG-REQUESTS), causing the memcpy to overflow the cmdlen-sized buffer.
Add a check that dataBytes <= cmdlen before the buffer allocation and
copy on the first request.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31833
CVE-2026-93517
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 2abe4632d7)
Each test starts its own X server via -displayfd, and pytest-xdist runs
several workers (meson several suites) in parallel. Servers scanning for a
free display number at the same time can both end up claiming the same one:
the losing test's client then connects to the winner's server, and when the
winner is torn down at the end of its own test the loser's connection dies
mid-test. It surfaces as an opaque
BrokenPipeError: [Errno 32] Broken pipe
test/pyxtest/xclient.py:270: in send_request / self.sock.sendall(data)
in an unrelated test, which looks like a flake and hides the cause.
Hold a cross-process lock for the short display-allocation window (Popen
plus reading the display number). Once a server has announced its display
it owns the socket and the lock file, so later servers skip that number and
that window is the only place the race can happen.
As a safety net, record the server PID that owns the socket (SO_PEERCRED)
and fail the xclient fixture with a clear message when it is not the server
the fixture started, instead of leaving a confusing BrokenPipeError.
Measured with a --buildtype=debug build and 4 pytest-xdist workers, 40
parallel pytest sessions of test_xi.py: before, 7 sessions failed with
"connected to PID X instead of the test server" and 5 with
BrokenPipeError; after, 0 of 40, plus 0 errors over 8 full test/pyxtest
runs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We make two glyphsets, GS1 and GS2, both with the same format depth.
GS1 contains any glyph different from the others, let's call it U
(unique). GS2 contains two glyphs with the same content, or at least
sha1 hash. Let's call them A and B.
We first register GS1 and GS2. GS1 has no problems, but before the
fix, registering GS2 breaks accounting in `globalGlyphs`. Since there
is no check for duplicate glyphs within a single set, we make two
`GlyphNew` entries for A and B. Now in the loop at the end, we go over
each entry and call `AddGlyph` and `FreeGlyph`:
1. AddGlyph(GS2, A, idA) inserts A into `globalGlyphs`
2. FreeGlyph(A) drops A's refcnt by one, but as it's being held in
`globalGlyphs` it's kept alive.
3. AddGlyph(GS2, B, idB) finds A in `globalGlyphs` and reuses it
instead of inserting B
4. FreeGlyph(B) drops B's refcnt by one (to zero), and B is freed.
Before the fix, the lookup in `globalGlyphs` finds A's entry, and
since it isn't a DeletedGlyph, it erroneously removes the
`gr->glyph` pointing to `A` and decrements `tableEntries`. This
results in `tableEntries` being off-by-one as `A` is still alive.
Now, we free the glyphsets in a particular order. Freeing GS1 results
in calling FreeGlyph(U), which will decrement U's refcnt to zero, and
free U. This clears out the entry in `globalGlyphs` for U and
decrements `tableEntries`, which due to the earlier error is now zero.
When `FreeGlyphSet` sees this, it clears the `globalGlyphs` for that
format depth. Now freeing A or GS2 (which transitively frees A) will
try to check the `globalGlyphs` at that format depth, but because it
was cleared out this crashes.
The fix here is to change FreeGlyph to only free a glyph from
`globalGlyphs` that is exactly the glyph being freed, so that
FreeGlyph(B) doesn't touch `globalGlyphs` at all. This keeps a proper
count in `tableEntries` and prevents `globalGlyphs[fdepth]` from being
freed before A is freed.
Closes: #1881
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2264>
(cherry picked from commit 81edc9caf557f7a44c5b308742814457de0eb6c0)
(cherry picked from commit 716d876142280cd66bdcf000f81428dadd5d3937)
Signed-off-by: Octavia Togami <octy@octyl.net>
This allows tests to use an xserver_args fixture/parameter to pass
arguments for the xserver fixture they may use.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2263>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Send a swapped ChangeDeviceControl/DEVICE_RESOLUTION with
num_valuators=255 and no valuator payload. Without the SProc length
check this overruns the request buffer; with it the server returns
BadLength.
Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2285>
(cherry picked from commit ddf3edc368)
(cherry picked from commit 3ed09c52d4a9cfe85b5f9d2f64beac022d79b221)
(cherry picked from commit 3f8dfe0169d563e147872a659ff461b95eeea16b)
The X11 core protocol error code constants (BadRequest, BadValue,
BadWindow, etc.) belong with the other protocol definitions in
proto/x11.py rather than in the client connection module.
Move the canonical definitions to proto/x11.py and re-export them from
xclient.py for backward compatibility. Update all test files to import
from proto.x11 instead.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2263>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
At this point, allowing X Font Server connections just introduces us to
possible security issues since the code effectively trusts any font
server and few checks are in place.
Since font servers also haven't been used for ages, let's disable
them by default. Use-cases that require them will have to pass
+fontserverconnections on the commandline and/or set the corresponding
ServerFlags option.
The tests are a bit hacky: Debian builds libXfont2 with --disable-fc so
we need to cater for the case where the X server enables fontserver support
but libXfont then blocks it and we still need to treat this as success.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2263>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XF86-BigFont lets local clients share font-metrics arrays via SysV
shared memory (and compresses them for remote clients) -- a local-only
optimization dating back to ancient XFree86. It hasn't been built by
default for really long time.
Enabling it in our CI immediately exposed that the code has bit-rotted
on 7 non-Linux CI lanes (macOS/BSD: including a nonexistent Linux-only
header; Solaris: an ARRAY_SIZE redefinition pulled in via its system
headers; mingw32: implicit geteuid()/getegid() plus an unused variable).
Concrete evidence that this extension currently has no real users
exercising it, since none of that breakage was ever noticed.
Therefore no practical need for carrying it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GLYPHWIDTHPIXELS and GLYPHHEIGHTPIXELS compute glyph dimensions from
signed INT16 fields. A crafted PCF font can produce negative results
(e.g. rightSideBearing < leftSideBearing).
All callees have a while (height--) loop which will end up in OOB writes
for negative height values.
In the case of a negative height, some callees cast to size_t or end up
with negative strides.
The same pattern exists in fbPoloyGlyphBit, miPolyGlyphBlt and
glamor_poly_glyph_blt_gl, so let's fix all of them in one go.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
(cherry picked from commit e31efd3e10)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
glamor_font_get() computes the atlas slot size from the font's declared
maxbounds, but copies each glyph's bitmap using the per-glyph metrics
(GLYPHHEIGHTPIXELS/GLYPHWIDTHBYTES macros). When a malicious PCF font
has per-glyph metrics exceeding maxbounds, the memcpy writes past the
heap-allocated atlas buffer. Negative per-glyph metrics are even worse:
the loop counter wraps to ~4 billion iterations (via unsigned cast) or
memcpy's size parameter wraps to SIZE_MAX.
The PCF parser in libXfont2 does not recompute maxbounds from per-glyph
data (only the BDF parser does), so the file's declared maxbounds values
are trusted as-is.
Reject fonts where any per-glyph metric is negative or exceeds the
atlas slot size, falling back to software rendering which uses per-glyph
metrics directly without an atlas.
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
CVE-2026-55999/ZDI-CAN-30498
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
(cherry picked from commit fbf7bac22e)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
oldTag in CommonMakeCurrent() is a pointer to cl->contextTags[...].
CommonMakeCurrent() may realloc(cl->contextTags) and thus move the
memory, leaving oldTag as dangling pointer.
If we then GlxFreeContextTag(oldTag) we end up writing into freed
memory.
Fix this by freeing oldTag before CommonMakeNewCurrent().
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
CVE-2026-56000/ZDI-CAN-30561
Fixes: 4781f2a5a8 ("GLX: Free the tag of the old context later")
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
(cherry picked from commit 2779affbdb)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a dedicated xserver-build-ubuntu-valgrind job that builds a debug
Xvfb and runs the pyxtest suite (test/pyxtest/) with --valgrind, so
memory errors (invalid reads/writes, use-after-free, uninitialised
value use) are caught in CI, not just OOB bugs ASAN happens to catch
locally.
The pytest-based harness (test/pyxtest/conftest.py, xserver.py,
valgrind.py) already implements valgrind support; it was simply never
wired into CI. pytest itself was also not installed in the Ubuntu CI
image, so the existing pyxtest suite has been silently skipped (not
built, since meson's find_program('pytest', required: false) found
nothing) on every other Ubuntu lane too. Installing python3-pytest
fixes that as a side effect: the normal xserver-build-ubuntu* jobs now
also actually run pyxtest (without valgrind) as part of "meson test",
exercising the existing protocol-fuzzing regression tests that were
previously dead weight.
Kept as a separate lane rather than adding --valgrind to the existing
run-xserver-build-and-test.sh: valgrind is slow, and pyxtest only
needs Xvfb, not the full Xorg/Xephyr/Xnest/XTS/piglit build the other
lanes carry.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On Solaris, to get information about the process on the other side of
a socket, we use the getpeerucred() system call instead of the
SO_PEERCRED socket option.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2241>
Add TestScreenSaverFreeAttr which exercises the ScreenSaverFreeAttr
code path by setting attributes, activating the screen saver, then
closing the client connection (triggering resource cleanup).
While ScreenSaverFreeAttr currently does not dereference pPriv after
CheckScreenPrivate, this test verifies the code path is safe and
would catch regressions if future code changes introduced a stale
pointer dereference (same pattern as ZDI-CAN-30168).
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add ListFonts, SetFontPath, and GetFontPath protocol builders to
proto/x11.py and a regression test that reproduces the
doListFontsAndAliases stack buffer overflow.
The test creates a temporary font directory with a fonts.alias file
containing an alias whose target name is 400 bytes -- exceeding the
old XLFDMAXFONTNAMELEN of 256 but under libXfont2's MAXFONTNAMELEN of
1024. It prepends this directory to the font path via SetFontPath, then
sends ListFonts matching the alias name. Without the fix, the server
would copy the oversized resolved name into a 256-byte stack buffer,
causing a stack buffer overflow.
ZDI-CAN-30136
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a regression test that reproduces the mapWidths stack buffer overflow
in CheckKeyTypes.
The test sends two XkbSetMap requests: first with firstType=0, nTypes=255,
ResizeTypes to expand the type table to 255 entries, then with
firstType=255, nTypes=10, ResizeTypes. The second request passes the
firstType > num_types check (255 > 255 is false) and computes
nMaps = 255 + 10 = 265. Without the fix, the loop would write
mapWidths[255..264], overflowing 9 bytes past the 256-element stack
buffer into adjacent stack variables.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a regression test that reproduces the XKB num_levels stack overflow.
The test sends an XkbSetMap request with XkbSetMapResizeTypes that includes
a non-canonical key type with numLevels=255, exceeding XkbMaxShiftLevel
(63). Without the fix, this type would be accepted and stored in the
server's type table. A subsequent ChangeKeyboardMapping would trigger
XkbUpdateKeyTypesFromCore -> XkbKeyTypesForCoreSymbols, where the
oversized num_levels is used as groupsWidth, causing indices into the
tsyms[252] stack buffer to reach up to 1019 and overflow.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add screensaver protocol builders for SetAttributes, UnsetAttributes, and
ForceScreenSaver, then add a regression test that reproduces the
CreateSaverWindow use-after-free.
The test sequence:
1. SetAttributes(root, 100x100, mask=0) - creates screen private with attr
2. ForceScreenSaver(Active) - creates the saver window
3. UnsetAttributes(root) - clears pPriv->attr to NULL
4. ForceScreenSaver(Active) - re-enters CreateSaverWindow
Without the fix, step 4 triggers CheckScreenPrivate which finds all fields
empty (attr=NULL, events=NULL, hasWindow=FALSE, installedMap=None), frees
pPriv, and sets the screen private to NULL. The function then dereferences
the freed pPriv->attr pointer, causing a use-after-free.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a regression test that reproduces the SyncChangeCounter use-after-free.
The test creates a counter (value=0) and issues SyncAwait with two
conditions on the same counter, both waiting for value >= 1. A second
client then calls SetCounter to set the value to 100. SyncChangeCounter
iterates triggers; the first fires and FreeAwait frees all sibling trigger
list nodes via SyncDeleteTriggerFromSyncObject. Without the fix, the saved
pnext pointer would dangle, and the next iteration would dereference freed
heap memory.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add SYNC extension protocol builders (proto/sync.py) and a regression test
that reproduces the miSyncDestroyFence and FreeCounter use-after-free.
The first test creates a fence and issues AwaitFence with the same fence ID
listed twice, creating two trigger list nodes pointing into one
SyncAwaitUnion. A second client then destroys the fence. Without the fix,
miSyncDestroyFence would invoke CounterDestroyed before saving the next
pointer, and the first callback would free the SyncAwaitUnion while the
second trigger list node still referenced it.
The second test creates a counter (value=0) and issues SyncAwait with two
conditions on the same counter, both waiting for value >= 1. Since the
counter is 0, Client A blocks. A second client then destroys the counter.
Without the fix, FreeCounter would invoke CounterDestroyed before saving
the next pointer in the trigger list, and the first callback would free
the SyncAwaitUnion while the second trigger node still referenced it.
ZDI-CAN-30163 (FreeCounter)
ZDI-CAN-30159 (miSyncDestroyFence)
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add GLX extension protocol builders (proto/glx.py) and a regression test
that reproduces the reversed length check in ChangeDrawableAttributes.
The test creates a GLX context on the root visual, binds it with
MakeCurrent (which auto-creates a GLXDrawable), then sends a
ChangeDrawableAttributes request with length=3 (12 bytes) but
numAttribs=2100. Without the fix, the reversed comparison operator (<
instead of >) would let this undersized request pass validation, and
DoChangeDrawableAttributes would iterate 2100 attribute pairs, reading
far past the 12-byte request buffer.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xclient.send_request() should just take a Request object and handle
to_bytes with the right byte order. This avoids typos/copy-paste errors
in tests when the byte order changes between tests.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2216>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This test was missing SetClientVersion(2) so the reply was a the old 0.x
protocol (and the 36 byte GetModeLine reply). Update so it runs for both
versions now.
Fixes: acbc46e708 ("pyxtest: add tests for the byteswapping patches")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2213>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We need a proper module tree set up so let's do this via symlinks during
the setup phase and then start the server with that as module path.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2213>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The test sends a PresentPixmap request with a notify entry from a
byte-swapped client. Without the fix, the window ID in the notify
is not swapped, causing dixLookupWindow to fail with BadWindow.
With the fix, the window ID is correctly interpreted.
See 925edb6c9e ("present: Fix missing byte swaps in sproc_present_pixmap()")
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2212>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This makes it much easier to debug an individual test since we can now
start an X server via valgrind/gdb/whatever and have the test client
connect to that server.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2187>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add tests for commit b243ef9bc2 ("Xi: Swap property data in
SProcXChangeDeviceProperty/SProcXIChangeProperty").
Both tests set a format=32 property from a byte-swapped client and
read it back, verifying the values round-trip correctly. Without the
property data swap, the stored values have the wrong byte order.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2187>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
