Similar to the recent fixes, add more _XkbCheckRequestBounds() to the
functions that loop over the request data, i.e.:
* CheckKeySyms()
* CheckKeyActions()
* CheckKeyBehaviors()
* CheckVirtualMods()
* CheckKeyExplicit()
* CheckVirtualModMap()
* _XkbSetMapChecks()
All these are static functions so we can add the client to the parameters
without breaking any API.
See also:
CVE-2026-34003, ZDI-CAN-28736, CVE-2026-34002, ZDI-CAN-28737
v2: Check for "nSyms != 0" in CheckKeySyms() to avoid false positives.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d38c563fab)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
The function CheckKeyTypes() will loop over the client's request but
won't perform any additional bound checking to ensure that the data
read remains within the request bounds.
As a result, a specifically crafted request may cause CheckKeyTypes() to
read past the request data, as reported by valgrind:
== Invalid read of size 2
== at 0x5A3D1D: CheckKeyTypes (xkb.c:1694)
== by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
== by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
== by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
== by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
== by 0x4A20DF: Dispatch (dispatch.c:551)
== by 0x4B03B4: dix_main (main.c:277)
== by 0x428941: main (stubmain.c:34)
== Address is 30 bytes after a block of size 28,672 in arena "client"
==
== Invalid read of size 2
== at 0x5A3AB6: CheckKeyTypes (xkb.c:1669)
== by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
== by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
== by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
== by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
== by 0x4A20DF: Dispatch (dispatch.c:551)
== by 0x4B03B4: dix_main (main.c:277)
== by 0x428941: main (stubmain.c:34)
== Address is 2 bytes after a block of size 28,672 alloc'd
== at 0x4848897: realloc (vg_replace_malloc.c:1804)
== by 0x5E357A: ReadRequestFromClient (io.c:336)
== by 0x4A1FAB: Dispatch (dispatch.c:519)
== by 0x4B03B4: dix_main (main.c:277)
== by 0x428941: main (stubmain.c:34)
==
== Invalid write of size 2
== at 0x5A3AD7: CheckKeyTypes (xkb.c:1669)
== by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
== by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
== by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
== by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
== by 0x4A20DF: Dispatch (dispatch.c:551)
== by 0x4B03B4: dix_main (main.c:277)
== by 0x428941: main (stubmain.c:34)
== Address is 2 bytes after a block of size 28,672 alloc'd
== at 0x4848897: realloc (vg_replace_malloc.c:1804)
== by 0x5E357A: ReadRequestFromClient (io.c:336)
== by 0x4A1FAB: Dispatch (dispatch.c:519)
== by 0x4B03B4: dix_main (main.c:277)
== by 0x428941: main (stubmain.c:34)
==
To avoid that issue, add additional bounds checking within the loops by
calling _XkbCheckRequestBounds() and report an error if we are to read
past the client's request.
CVE-2026-34003, ZDI-CAN-28736
This vulnerability was discovered by:
Jan-Niklas Sohn working with TrendAI Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b85b00dd7b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
As reported by valgrind:
== Conditional jump or move depends on uninitialised value(s)
== at 0x547E5B: CheckModifierMap (xkb.c:1972)
== by 0x54A086: _XkbSetMapChecks (xkb.c:2574)
== by 0x54A845: ProcXkbSetMap (xkb.c:2741)
== by 0x556EF4: ProcXkbDispatch (xkb.c:7048)
== by 0x454A8C: Dispatch (dispatch.c:553)
== by 0x462CEB: dix_main (main.c:274)
== by 0x405EA7: main (stubmain.c:34)
== Uninitialised value was created by a heap allocation
== at 0x4840B26: malloc (vg_replace_malloc.c:447)
== by 0x592D5A: AllocateInputBuffer (io.c:981)
== by 0x591F77: InsertFakeRequest (io.c:516)
== by 0x45CA27: NextAvailableClient (dispatch.c:3629)
== by 0x58FA81: AllocNewConnection (connection.c:628)
== by 0x58FC70: EstablishNewConnections (connection.c:692)
== by 0x58FFAA: HandleNotifyFd (connection.c:809)
== by 0x593F42: ospoll_wait (ospoll.c:660)
== by 0x58B9B6: WaitForSomething (WaitFor.c:208)
== by 0x4548AC: Dispatch (dispatch.c:493)
== by 0x462CEB: dix_main (main.c:274)
== by 0x405EA7: main (stubmain.c:34)
The issue is that the loop in CheckModifierMap() reads from wire without
verifying that the data is within the request bounds.
The req->totalModMapKeys value could exceed the actual data provided,
causing reads of uninitialized memory.
To fix that issue, we add a bounds check using _XkbCheckRequestBounds,
but for that, we need to also pass a ClientPtr parameter, which is not
a problem since CheckModifierMap() is a private, static function.
CVE-2026-34002, ZDI-CAN-28737
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit f056ce1cc9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
As reported by valgrind:
== Invalid read of size 8
== at 0x568C14: miSyncTriggerFence (misync.c:140)
== by 0x540688: ProcSyncTriggerFence (sync.c:1957)
== by 0x540CCC: ProcSyncDispatch (sync.c:2152)
== by 0x4A28C5: Dispatch (dispatch.c:553)
== by 0x4B0B24: dix_main (main.c:274)
== by 0x42915E: main (stubmain.c:34)
== Address 0x17e35488 is 8 bytes inside a block of size 16 free'd
== at 0x4843E43: free (vg_replace_malloc.c:990)
== by 0x53D683: SyncDeleteTriggerFromSyncObject (sync.c:169)
== by 0x53F14D: FreeAwait (sync.c:1208)
== by 0x4DFB06: doFreeResource (resource.c:888)
== by 0x4DFC59: FreeResource (resource.c:918)
== by 0x53E349: SyncAwaitTriggerFired (sync.c:701)
== by 0x568C52: miSyncTriggerFence (misync.c:142)
== by 0x540688: ProcSyncTriggerFence (sync.c:1957)
== by 0x540CCC: ProcSyncDispatch (sync.c:2152)
== by 0x4A28C5: Dispatch (dispatch.c:553)
== by 0x4B0B24: dix_main (main.c:274)
== by 0x42915E: main (stubmain.c:34)
== Block was alloc'd at
== at 0x4840B26: malloc (vg_replace_malloc.c:447)
== by 0x5E50E1: XNFalloc (utils.c:1129)
== by 0x53D772: SyncAddTriggerToSyncObject (sync.c:206)
== by 0x53DCA8: SyncInitTrigger (sync.c:414)
== by 0x5409C7: ProcSyncAwaitFence (sync.c:2089)
== by 0x540D04: ProcSyncDispatch (sync.c:2160)
== by 0x4A28C5: Dispatch (dispatch.c:553)
== by 0x4B0B24: dix_main (main.c:274)
== by 0x42915E: main (stubmain.c:34)
When walking the list of fences to trigger, miSyncTriggerFence() may
call TriggerFence() for the current trigger, which end up calling the
function SyncAwaitTriggerFired().
SyncAwaitTriggerFired() frees the entire await resource, which removes
all triggers from that await - including pNext which may be another
trigger from the same await attached to the same fence.
On the next iteration, ptl = pNext points to freed memory...
To avoid the issue, we need to restart the iteration from the beginning
of the list each time a trigger fires, since the callback can modify the
list.
CVE-2026-34001, ZDI-CAN-28706
This vulnerability was discovered by:
Jan-Niklas Sohn working with TrendAI Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit f19ab94ba9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
As reported by valgrind:
== Conditional jump or move depends on uninitialised value(s)
== at 0x5CBE66: SrvXkbAddGeomKeyAlias (XKBGAlloc.c:585)
== by 0x5AC7D5: _CheckSetGeom (xkb.c:5607)
== by 0x5AC952: _XkbSetGeometry (xkb.c:5643)
== by 0x5ACB58: ProcXkbSetGeometry (xkb.c:5684)
== by 0x5B0DAC: ProcXkbDispatch (xkb.c:7070)
== by 0x4A28C5: Dispatch (dispatch.c:553)
== by 0x4B0B24: dix_main (main.c:274)
== by 0x42915E: main (stubmain.c:34)
== Uninitialised value was created by a heap allocation
== at 0x4840B26: malloc (vg_replace_malloc.c:447)
== by 0x5E13B0: AllocateInputBuffer (io.c:981)
== by 0x5E05CD: InsertFakeRequest (io.c:516)
== by 0x4AA860: NextAvailableClient (dispatch.c:3629)
== by 0x5DE0D7: AllocNewConnection (connection.c:628)
== by 0x5DE2C6: EstablishNewConnections (connection.c:692)
== by 0x5DE600: HandleNotifyFd (connection.c:809)
== by 0x5E2598: ospoll_wait (ospoll.c:660)
== by 0x5DA00C: WaitForSomething (WaitFor.c:208)
== by 0x4A26E5: Dispatch (dispatch.c:493)
== by 0x4B0B24: dix_main (main.c:274)
== by 0x42915E: main (stubmain.c:34)
Each key alias entry contains two key names (the alias and the real key
name), each of size XkbKeyNameLength.
The current bounds check only validates the first name, allowing
XkbAddGeomKeyAlias to potentially read uninitialized memory when
accessing the second name at &wire[XkbKeyNameLength].
To fix this, change the value to check to use 2 * XkbKeyNameLength to
validate the bounds.
CVE-2026-34000, ZDI-CAN-28679
This vulnerability was discovered by:
Jan-Niklas Sohn working with TrendAI Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 81b6a34f90)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
If the "compat" buffer has previously been truncated, there will be
unused space in the buffer. The code uses this space, but does not
update the number of valid entries in the buffer.
In the best case, this leads to the new compat entries being ignored. In the
worst case, if there are any "skipped" compat entries, the number of
valid entries will be corrupted, potentially leading to a buffer read
overrun when processing a future request.
Set the number of used "compat" entries when re-using previously
allocated space in the buffer.
CVE-2026-33999, ZDI-CAN-28593
This vulnerability was discovered by:
Jan-Niklas Sohn working with TrendAI Zero Day Initiative
Signed-off-by: Peter Harris <pharris2@rocketsoftware.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b024ae1749)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>
Nettle 2.6 (released in 2013) split the sha.h header into sha1.h & sha2.h,
but left the sha.h header for compatibility until the recent Nettle 4.0
release finally removed it.
Nettle 4.0 also dropped the length argument from the sha1_digest function.
Closes: #1871
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Before this commit the count of key type level names was wrongly set
in `XkbGetNames`: for key type without names, it was set to the level
count, while it should be 0:
- `XkbComputeGetNamesReplySize()` does not account key type without
level names;
- `XkbSendNames()` does not write any level entry for key types without
level names.
This causes a mismatch offset while parsing the response and its
processing would ultimately fail.
Fixed by setting the correct level name count: 0 if there is no level
name, else the number of levels.
(cherry picked from commit c49cbc176a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
A key type that has no level names is legit. Before this commit,
`XkbCopyKeymap` would make such level inconsistent by setting its
number of levels to 0 while keeping its map entries. It suffices
to clear the names array.
Fixed by copying the level count from the source type.
WARNING: this will trigger an error in `XkbGetNames`, which worked
before this commit only by chance. This is fixed in the next commit.
(cherry picked from commit 12605989af)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
When a group indicator (or a latched indicator of any kind) is defined,
e.g.:
indicator "Scroll Lock" { groups = Group2; }
the logical and physical indicator state may desync across multiple
connected keyboards.
This is caused by XkbPushLockedStateToSlaves only pushing locked_mods to
the slave devices. Pushing locked_group (as well as latched groups/mods)
along with locked_mods resolves the issue.
The issue is not observed with API calls because a different code path
is taken (avoiding XkbPushLockedStateToSlaves altogether).
Signed-off-by: Alexander Melnyk <inboxnumberzero@zoho.com>
(cherry picked from commit 36a7fdd315)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 6a4ec30af4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit c6522229b8)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be
a valid pixmap, but gcc's static analyzer doesn't and needs to be told.
Silences false positive reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit a79bdc495e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Unlike GetPictureScreen(), GetPictureScreenIfSet() checks if the
private key is registered, and returns NULL if it is not.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor.c:926:5:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘ps’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 69b48423bd)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Build breaks with gcc 14 & later when xf86bigfont is enabled:
../Xext/xf86bigfont.c: In function ‘XFree86BigfontExtensionInit’:
../Xext/xf86bigfont.c:709:28: error: implicit declaration of function
‘xfont2_allocate_font_private_index’;
did you mean ‘AllocateFontPrivateIndex’? [-Wimplicit-function-declaration]
709 | FontShmdescIndex = xfont2_allocate_font_private_index();
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| AllocateFontPrivateIndex
Fixes: 05a793f5b ("dix: Switch to the libXfont2 API (v2)")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 0617f6075b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
In most typical Linux X servers (like Xvfb, Xephyr, or Xwayland), no child process outlives the server, so this issue rarely arises. However, in embedded X servers (based on Xvfb or Kdrive) or in custom Xorg modules, the server might launch a long-running command with regular fork+exec calls. If the X server crashes or exits while that command is still running (for example, it spawns a tombstone generator or any process that hangs or turns to zombie), the file descriptor associated with the abstract socket can remain open in the child process. This leads to the kernel refusing to allow another X server to bind the same socket until the child process terminates (because there is no explicit way to unlink abstract socket, unlike Unix socket). By marking the file descriptor as close-on-exec, we ensure it is automatically closed in child processes, preserving the ability of a new X server process to bind the socket immediately.
Signed-off-by: Twaik Yont <9674930+twaik@users.noreply.github.com>
(cherry picked from commit 5568b0f83f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
When compiling with gcc 15.2.0 using -O3 -m64 on Solaris SPARC & x64,
we'd get a test failure of:
Assertion failed: strcmp(logmsg, expected) == 0,
file ../test/signal-logging.c, line 339, function logging_format
because 'num *= 1' produced a value that was out of the range of the
int64_t it was being stored in. (Compiling with -O2 worked fine with
the same compiler/configuration/platform though.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 7f68b58865)
(cherry picked from commit 3eac9393d7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
This fix use after free when a pluggable gpu screen (such as displaylink)
was set as primary screen and unpluged.
gdb backtrace:
#0 OssigHandler (signo=11, sip=0x7fff2e0a50f0, unused=0x7fff2e0a4fc0) at ../../../../os/osinit.c:138
#1 <signal handler called>
#2 rrGetscreenResources (client=0x3195160, query=0) at ../../../../randr/rrscreen.c:577
#3 0x0000000000562bae in ProcRRGetscreenResourcesCurrent (client=0x3195160) at ../../../../randr/rrscreen.c:652
#4 OxOOOOB0000054de63 in ProcRRDispatch (client=0x3195160) at ../../../../randr/randr.c:717
#5 0x00000000004322c6 in Dispatch () at ../../../../dix/dispatch.c:485
#6 0x0900900990443139 in dix_main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/main.c:276
#7 0X0000000000421d9a in main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/stubmain.c:34
Signed-off-by: hongao <hongao@uniontech.com>
(cherry picked from commit 1443fd34ea)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
the license notice comes from these files:
- dix/registry.c
- Xext/xselinuxint.h
- Xext/xselinux_label.c
- Xext/xselinux_hooks.c
- Xext/xselinux_ext.c
- Xext/xselinux.h
- Xext/xacestr.h
- Xext/xace.h
- Xext/xace.c
while this is not like the standard `Copyright (C)` lines I think it
still belongs to the license, even if just to make it more clearly
separate from the MIT license above
(cherry picked from commit fff0023339)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
In the `doListFontsAndAliases` function in dixfonts.c, when a font alias
is encountered (`err == FontNameAlias`) as a result of
`list_next_font_or_alias` call, the code allocates memory for
`resolved` variable (`resolvedlen + 1` bytes) for storing target font
name. In this case, if the `malloc(resolvedlen + 1)` call fails,
`resolved` remains NULL.
Later, when check (`else if (err == FontNameAlias)`) is TRUE, the code
uses `memcpy` to copy nullable `resolved` into `tmp_pattern` without
checking if `resolved` is NULL, so there is a potential null ptr
dereference.
This commit replaces `malloc` with `XNFalloc` for allocating memory for
`resolved`. `XNFalloc` will internally check result of `malloc` and stop
program execution if allocation was failed, preventing potential NULL
dereferencing.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 0237462d32)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Free nested allocations when initialization fails.
Several code paths returned early on error without releasing
memory owned by embedded structures, leading to leaks.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 809402414e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
In `Fopen` function variable `iop` may store NULL as a result of `fopen`
call. In this case, if later privileges couldn't be restored (`seteuid`
call fails), further `fclose(iop)` call will cause runtime error.
This commit adds check `iop` for NULL before calling `fclose` to prevent
potential NULL pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit f83807647e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
dixLookupResourceByType always overwrites the pointer passed in as the
first arg, so we shouldn't use the union it's in after that to get the
requested XID value to put in the errorValue.
Closes: #1857
Fixes: 2d7eb4a19 ("Pre-validate ChangeGC XIDs.")
Reported-by: Mouse <mouse@Rodents-Montreal.ORG>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit ac42c39145)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
The Render extension operates on PictFormats rather than GC, so it
bypasses the rootless layer's GC-based alpha protection
(ROOTLESS_PROTECT_ALPHA). Depth-24 windows use PICT_x8r8g8b8 where
the 'x' tells pixman the high byte is padding it may freely zero.
The macOS compositor needs this byte to be 0xFF (opaque).
Before each Render operation that targets a rootless window,
temporarily upgrade the destination Picture's format from
PICT_x8r8g8b8 to PICT_a8r8g8b8. This tells pixman that the alpha
channel is significant and must not be optimized away. The format
is restored after the operation completes.
This parallels how ROOTLESS_PROTECT_ALPHA handles GC operations (by
masking alpha out of the planemask) and how ROOTLESS_SAFEALPHA
handles PaintWindow (by forcing alpha in solid fills). The
save/restore approach is analogous to rootlessGC.c's GC_SAVE /
GC_RESTORE pattern.
Fixes [2/2]: https://github.com/XQuartz/XQuartz/issues/31
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit d2e83a266c)
The Render extension's Trapezoids and Triangles operations
(fbTrapezoids, fbTriangles) render directly via pixman through
fbShapes without going through ps->Composite, so RootlessComposite
never fires for these operations. This means RootlessStartDrawing
is not called and the macOS compositor is not notified of changed
pixels.
Add RootlessTrapezoids and RootlessTriangles wrappers following the
same pattern as RootlessComposite: call RootlessStartDrawing before
the operation, then compute the bounding box via miTrapezoidBounds or
miTriangleBounds and call RootlessDamageBox after. The default
miTriStrip and miTriFan implementations decompose their input into
triangles and dispatch through ps->Triangles, so the RootlessTriangles
wrapper covers TriStrip and TriFan as well.
Also add a RootlessCompositeRects wrapper as defense-in-depth. The
current miCompositeRects implementation already has partial rootless
coverage: PictOpSrc/PictOpClear go through the GC layer, and other
ops route through CompositePicture -> RootlessComposite. Wrapping at
the PictureScreen level ensures robustness regardless of the underlying
implementation.
Fixes [1/2]: https://github.com/XQuartz/XQuartz/issues/31
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 40b762cf6d)
RootlessGlyphs used max() for box.x1 and box.y1 when accumulating the
bounding box across glyphs in a list. Computing the union of bounding
boxes requires min() for the lower coordinate corner and max for the
higher coordinate corner.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit e8936920ee)
This reverts commit 0a1ee643b2.
This is causing a number of regressions on existing setups:
* Reverse PRIME with the NVIDIA proprietary driver, where software
rendering is used instead of the NVIDIA GLX library with hardware
acceleration
* Performance issues with AMDGPU
* Rendering with 10-bit output with AMDGPU
Revert the change that is causing these regressions in the stable branch.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1848
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2104>
The script comes from a backport where only meson is used and therefore
the new files were omitted from the Makefile.
As a result, these files are not included in the released tar file and
the build fails.
Fixes: 95b899118 - meson: add glamor gles2 tests
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2089>
