No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have it split into two functions one just wrapping
another, so move it all into one.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only caller already has a pointer to client struct, so no need to
let this function look it up again in the global clients array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always enabled for very long time now (at least since meson transition),
there doesn't seem to be any need to ever disable it again. So we can reduce
code complexity by removing all the ifdef's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific pixmap destruction procedures are implemented
by wrapping the ScreenRec's DestroyPixmap() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
It's even getting worse: the proc also has to do ref counting, and only destroy
the pixmap if refconter reaching zero - that's all done in the individual screen
drivers. Therefore, all extensions must check for refcnt == 1, in order to know
when to really act.
This commit introduces a simple approach for letting extension hook into the
pixmap destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If a cursor reference count drops to 0, the cursor is freed.
The root cursor however is referenced with a specific global variable,
and when the root cursor is freed, the global variable may still point
to freed memory.
Make sure to prevent the rootCursor from being explicitly freed by a
client.
CVE-2025-26594, ZDI-CAN-25544
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
v2: Explicitly forbid XFreeCursor() on the root cursor (Peter Hutterer
<peter.hutterer@who-t.net>)
v3: Return BadCursor instead of BadValue (Michel Dänzer
<michel@daenzer.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Make dixDestroyPixmap() check for NULL pointer, so callers don't need to
do it anymore. Returning TRUE on NULL pointer - but most callers won't
even look at the retval anyways.
Together with subsequent commits, which will make use of that function,
instead of calling raw ScreenRec->DestroyPixmap vectors, this gives us some
more freedom for architectural changes, eg. get rid of the extremely
complicated and fragile wrapping chains.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1709>
PANORAMIX was the original working title of the extension, before it became
official standard. Just nobody cared about fixing the symbols to the official
naming.
For backwards compatibility with drivers, the old PANORAMIX symbol will
still be set.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1258>
The client.h file is part of the public module API, but it also contains
definitions that aren't useful for being used in modules. Splitting them
out into their own client_priv.h file, which isn't part of the API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The dix-config.h include file is always present, so no need for
an extra check and conditional include.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, so no need to keep them exported.
As already touching them, give them a proper name prefix for clarity.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1581>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
Enrico Weigelt, metux IT consult
Olivier Fourdan