When doing reverse PRIME, the buffer being scaned out is still the front
BO.
Properly reuse its fb_id, to prevent adding a FB for the front_bo each
time the fb_id is requested.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2064>
The old ones didn't know the block size, so couldn't deduce the block
type version. With upcoming new features, eg. HDR, we need to know the
block type version in order to know what we can extract from it.
This new function should now be used by all drivers, the old ones shall
be phased out.
That commit should be backported to 25.0 and 25.1 releases, so drivers
can remain compatible with all existing release lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The fix in e2550d065b wrongly assumes
crtc->f_transform only contain rotation and ignores translation part,
which causes function to return erroneous BadMatch when it called. This
commit fixes it.
Closes: https://github.com/X11Libre/xserver/issues/2159
Signed-off-By: Tautvis <gtautvis@gmail.com>
Protect against SEGFAULT in cases where per-screen damage private
hasn't been initialized yet or already destroyed, or function pointers
not implemented.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
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>
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/2133>
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>
When switching vt to an X server using the vesa driver,
the driver needs access to a high io port, which segfaults
if only the first 1024 io ports are enabled.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
-----------------------------------------------------------
Fix mach64 driver crash
Due to lack of iopl(3), mach64 driver crashes when ior(BUS_CNTL) is
called. Since BUS_CNTL is out of the range 0x0000-0x03ff, ioperm(0,
1024, 1) is not sufficient and the ior() causes access violation.
This patch reintroduce iopl(3) call in the function hwEnableIO().
Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110521
Fixes: a0f738a673 ("Fixed ioperm calls in hwEnableIO")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2052>
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>
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.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Changes message issued for too many clocks from the confusing:
"29.0" is not a valid keyword in this section.
to the more obvious:
More than 128 Clocks defined.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2130>
Re-map the SELinux security classes on policy loads, as the mapping will
be desynchronized (see man:selinux_set_mapping(3)) and audit messages
will not show the actual class and permission names:
USER_AVC pid=24283 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xorg_t:s0 msg='avc: denied { 0x10 } for request=XFIXES:SelectSelectionInput comm=/usr/bin/python3 resid=6400001 restype=WINDOW scontext=xuser_u:xuser_r:systemd_user_instance_generic_bin_t:s0 tcontext=xuser_u:object_r:xorg_t:s0 tclass=(null) permissive=1
In addition use type-safe assignments.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/801>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1553>
Only generate audit events for messages of the type avc (permission
denied) and error (e.g. invalid context).
For example avoid USER_SELINUX_ERR for policy load events:
audit[980]: USER_SELINUX_ERR pid=980 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xorg_t:s0 msg='avc: op=load_policy lsm=selinux seqno=8 res=1 exe="/usr/lib/xorg/Xorg" sauid=0 hostname=? addr=? terminal=?'
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/801>
When validating the size passed to SetScreenSize, the CRTC mode size
needs to be applied the full CRTC transform, otherwise the check may
bogusly fail.
Do a full transform on the CRTC mode size when checking the
SetScreenSize request size instead of the current code that only
manually handles rotation.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1971>
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.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
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>
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>
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>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2125>
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>
This reverts commit 2ab2454151
In the pParent->drawable.depth == pWin->drawable.depth case, pWin may
already have valid contents, which need to be copied to the new pixmap.
Yet another old Xorg bug: the even masks are transmitted as CARD32's,
so they also need to be byte-swapped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
replacement for GTF_SUPPORTED() macro that's not a good API isolation
at all. Drivers should use that function instead for checking whether
the monitor supports GTF.
Should be backported to older releases, too - so drivers don't need
extra per-Xserver-version tweaks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When running in a virtual machine, the cursor pitch
may not behave the same as it does on bare metal.
This patch disables a power consumption optimization
when running in a vm, working around the cursor pitch issues.
This means that some vm users who previously had a working
cursor pitch may now see some increased power consumption.
Fixes: https://github.com/X11Libre/xserver/issues/1816
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
os.h still defining our own timingsafe_memcmp() prototype when this
symbol isn't set - this is causing trouble with drivers on FreeBSD.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This functions is designed for some legacy keyboard drivers
(eg. xf86-input-keyboard) that need to get the fd to the console
device, so they don't need to directly access xf86Info field anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Call dixDestroyPixmap instead pScreen->DestroyPixmap, which is correct
call to free resources as since cece84fa93
the Screen->DestroyPixmap function is no longer wrapped.
Fixes: https://github.com/X11Libre/xserver/issues/1809
Signed-off-By: Tautvis <gtautvis@gmail.com>
