These functions aren't supposed to be used by drivers, so move them
out of the public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
fix warning on duplicated typedef:
> In file included from ../dix/main.c:86:
> ../dix/callback_priv.h:10:31: warning: redefinition of typedef 'CallbackListPtr' is a C11 feature [-Wtypedef-redefinition]
> typedef struct _CallbackList *CallbackListPtr;
> ^
> ../include/callback.h:60:31: note: previous definition is here
> typedef struct _CallbackList *CallbackListPtr; /* also in misc.h */
> ^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
fix warning:
> In file included from ../hw/xfree86/common/xf86Init.c:53:
> In file included from ../include/input.h:51:
> ../include/screenint.h:55:25: warning: redefinition of typedef 'ScreenPtr' is a C11 feature [-Wtypedef-redefinition]
> typedef struct _Screen *ScreenPtr;
> ^
> ../dix/screenint_priv.h:11:25: note: previous definition is here
> typedef struct _Screen *ScreenPtr;
> ^
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>
Make it clear that stuff from this file really isn't supposed to be used
by dynamically loaded modules like drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The DDX callbacks (where core/DIX calls into DDX) aren't supposed to be
called by drivers directly, so unexport them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Public server module API shouldn't be clobbered with private definitions,
thus move them out to private header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only used for record extension, no external callers, thus doesn't
need to be exported. Since it's just for retrieving one struct value,
it's not needed at all - we can do this directly (just like we do in
many other places)
Note: the check on noPanoramixExtensions is superfluous, since the only
call site already does it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not good having the public server api headers clobbered with private
definitions, so cleaning them up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Reduce cluttering public interface with non-exported stuff, moving those
things into a separate internal header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The xnfreallocarray was added along (and just as an alias to) XNFreallocarray
back a decade ago. It's just used in a few places and it's only saves us from
passing the first parameter (NULL), so the actual benefit isn't really huge.
No (known) driver is using it, so the macro can be dropped entirely.
Fixes: ae75d50395
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
For now, new selection objects are only created in ProcSetSelectionOwner()
when dixLookupSelection() can't find the requested one (returns BadMatch).
When somebody's trying to listen on a not-yet existing selection, via
XFixesSelectSelectionInput() -- XFIXES:SelectSelectionInput message -- he's
also getting BadMatch. This isn't neccessarily completely wrong, the spec
doesn't really tell anything about those situations (it doens't tell anything
about selection's lifetimes, just their ownerships). But there are real-
world clients not expecting an error here and crashing - the problem popped
up just recently, due to a necessary security fix (remote memory corruption
plus XACE missing to catch SelectSelectionInput) that alread went unnoticed
for far too long (*1).
So, it's better being polite and interpret the spec in the way that any
potential selection exists as soon as it's used by someone. (in fact, they
never get deleted anyways, just cleared).
XACE consumers get properly notified by the new Selection object creation
(eg. SElinux is attaching it's private data to it). And all callers already
prepared to get a cleared Selection object, because that's always been a
perfectly normal situation - Selection objects never get removed again,
just cleared.
*1) 601fd0fd84
X-Fixes: 601fd0fd84
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>
Enrico Weigelt, metux IT consult