Add tiny skeleton for the namespace extension. Disabled by default,
can be enabled via +extension arg, but doesn't actually do something yet.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are used by the in-tree libwfb.so module. As long as this an shared
object, instead of being directly linked into the executable, these symbols
need to be in the executable's symbol table. Nevertheless, they're not making
them part of the public SDK/module ABI, unless there's a really hard reason.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code is easier to understand when variables are declared where they're
used for the first time, scoped to where they're needed and not reused
for separate things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several sources including it without need. For consistency, those who still
need someting from there should include exitinit_priv.h (which also pulls
in extinit.h)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's last users gone about 15 years ago with commit
a715de7f11, so no need
to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
micmap.c is the only consumer of these, so move them into there,
instead of maintaining them in the public API w/o any practical need.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This .c file is the only consumer of that define, so move it
there instead of carrying it around in public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it public.
Also add some type-safety by implementing it as static inline function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not using anything from colormapst.h
* but several other includes have been missing (consumers had to
include them separately before that file)
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>
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>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on window positioning are implemented
by wrapping the ScreenRec's PositionWindow() 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.
This commit introduces a simple approach for letting extension hook into the
window positioning path safely, w/o having to care much about side effects
with the call chain. Extensions now can simply register their hook proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
It's also so simple (and rarely called) that easily can be inlined.
Also unexport HWEventQueueType and HWEventQueuePtr, since they're
not used by any drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's really no practical use for disabling GEEext, would just
cause the Xserver misbehaviour (eg. missing byte swapping)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1812>
Already in place for some functions, let's add it to most others.
The only function missing is miPointerSetPosition() which needs to
return the ScreenPtr and that one is unclear if we don't have a screen -
returning NULL will crash the caller(s) so let's wait for something to
trigger this bug before we try to fix it wrongly.
Related to #1782
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1771>
If a device is disabled, its master device is forcibly reset to NULL but
unlike a floating device it doesn't have a sprite allocated. Calling
miPointerGetPosition for a disabled device thus crashes.
Avoid this by returning 0/0 for any device without a miPointer.
This is a quick fix only, a proper fix for this issue is rather more
involved.
Closes#1782
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1771>
Xrdp project request exporting this function again, because (unlike the
usual xf86-video-* drivers) they need their own custom cursor handling:
RDP is designed to draw cursors on client side.
Also documenting what the function does.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1787>
Since ErrorF() is now signal safe, we can use this one instead.
Leaving ErrorFSigSafe() macro for backwards compat with drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1691>
stefan11111
dasha_uwu
Mike Gelfand
Enrico Weigelt, metux IT consult
Alan Coopersmith
Peter Hutterer