Commit 0e08e5083 ("xwayland: prevent X11 get enter event when pointer is
over Wayland client") introduced a pointer crossing count to avoid
sending spurious pointer enter events when the pointer is withing a
Wayland native surface.
However, that change breaks tablet devices, as the pointer enter count
is only updated from the wl_pointer enter/leave events, a slave X11
device such as a tablet pointer would report a lost focus and the event
wrongly sent to the root window.
To avoid the issue, revert partially commit 0e08e5083 to return FALSE
as before for the slave devices. The rest of the logic from commit
0e08e5083 remains unchanged, so that we do not send spurious
XCrossingEvents for the pointer device when it's within a native Wayland
surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1884
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2180>
newPix leaks if AddResource() call failes inside the FOR_NSCREENS
loop (per-screen pixmap IDs).
free newPix in mentioned execution path to prevent potential leak.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2173>
len calculation and strncpy limit were off by one when prefixing
"vmod_" to the virtual modifier name. This could write the final
NULL one byte past the allocated buffer from tbGetBuffer().
Use proper allocation len for prefix to avoid writing out-of-bounds.
Found by Linux Verification Center (linuxtesting.org) with SVACE
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2175>
The window name buffer after XWDFileHeader is fixed at
XWD_WINDOW_NAME_LEN (60 bytes). sprintf could overflow when
hostname is close to maximum length and combined with the
prefix "Xvfb " + display + screen number.
Switch to snprintf to guarantee we never write beyond the
allocated buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2172>
In XkbAddGeomDoodad(), when adding a doodad to a specific section
(section != NULL), there is a comparison between section->num_doodads
and geom->sz_doodads instead of the section's own section->sz_doodads.
The else branch (global geometry doodads) was already correct.
Compare section->num_doodads against section->sz_doodads to prevent
a potential out-of-bounds.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2174>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2176>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../xkb/xkbInit.c:527:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘rmlvo_dflts.layout’
xwayland-24.1.6/redhat-linux-build/../xkb/xkbInit.c:527:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘rmlvo_dflts.model’
xwayland-24.1.6/redhat-linux-build/../xkb/xkbInit.c:527:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘rmlvo_dflts.options’
xwayland-24.1.6/redhat-linux-build/../xkb/xkbInit.c:527:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘rmlvo_dflts.rules’
xwayland-24.1.6/redhat-linux-build/../xkb/xkbInit.c:527:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘rmlvo_dflts.variant’
Fixes: 56a5955c8 ("xkb: strdup the values returned by XkbGetRulesDflts")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2169>
Now that the Intel driver is no longer the default case, we don't
need to maintain a long list of entries to override the default.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2168>
Tell the compiler not to warn us that malloc could possibly return NULL
in this unit test.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../test/damage/primitives.c:97:13:
warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL
‘get_image(setup, *setup.d) + (long unsigned int)i * 4’
xwayland-24.1.6/redhat-linux-build/../test/damage/primitives.c:97:27:
warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL
‘setup.start_drawable_contents’
Fixes: 89901e14d ("test: Add the start of a testsuite for damage.")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2167>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../test/damage/primitives.c:68:43:
warning[-Wanalyzer-malloc-leak]: leak of ‘get_image(setup, *setup.d)’
Fixes: 89901e14d ("test: Add the start of a testsuite for damage.")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2167>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../render/glyph.c:388:26:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘hashSet’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2166>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../randr/rrscreen.c:848:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘size’
Move the use of the pointer inside the body of the if statement that
allocates the pointer so the static analyzer doesn't have to understand
the various conditions are effectively equivalent, despite the different
ways they are expressed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2165>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../randr/rrproviderproperty.c:419:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘temppAtoms’
The NULL dereference was flagged because the compiler didn't realize that
the loop to dereference the pointer would have 0 iterations if the
pointer hadn't been allocated. Moving it inside the if (numProps) check
made the dereference condition match the allocation condition so that the
gcc static analyzer was satisfied.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2165>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../randr/rroutput.c:540:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
The NULL dereference was only theoretically possible if the sum of
the sizes wrapped around to 0, but this ensures a NULL dereference
won't happen even in that case.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2165>
Since this is in initial startup, and other errors in this function are
already fatal, just make allocation failure of this small structure be
fatal as well, since if the X server is already out of memory it will
be dying soon anyway.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../os/xdmcp.c:1514:13:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘mcastinfo’
xwayland-24.1.6/redhat-linux-build/../os/xdmcp.c:1513:25:
acquire_memory: this call could return NULL
xwayland-24.1.6/redhat-linux-build/../os/xdmcp.c:1514:13:
danger: ‘mcastinfo’ could be NULL: unchecked value from (9)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2163>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../os/utils.c:1108:9:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘result’
xwayland-24.1.6/redhat-linux-build/../os/utils.c:1108:9:
danger: ‘malloc((long unsigned int)len + 18)’ could be NULL:
unchecked value from (3)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2163>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../hw/vfb/InitOutput.c:416:13:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘ppix’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2161>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glx/glxcmds.c:126:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘pVisual’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2160>
Changes behavior when a non-UTF-8 character is found from exiting the
script with a Python exception traceback and no clue which file had it
to reporting the filename and continuing to check the remaining files.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2158>
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>
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>
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>
When Xwayland is used rootful with hidpi, a viewport is in effect and a
scale applied.
This is however "transparent" to the Xserver which uses unscaled
coordinates, so to set the fake cursor position with a viewport and a
scale applied, we need to factor the scale to the coordinates before
passing the coordinate to the Wayland compositor through the method
zwp_locked_pointer_v1_set_cursor_position_hint().
Failing to do that will introduce a shift when warping the cursor
position.
v2: Use an xwl_window instead of an xwl_seat to improve readability
(Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1875
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2145>
xorg/lib/libx11@487e9489d1e086cc62c53045206ab6d6d9d02031
fixed the libX11 build to work with -fno-common (the new gcc default)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2141>
Clone freetype from its new home on freedesktop.org instead of its
old home on the GNU savannah
Remove extra / from font/util URL path
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2141>
