Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window position 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>
Right now, extension specific window destruction procedures are implemented
by wrapping the ScreenRec's DestroyWindow() 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 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>
This new lookup function retrieves a pointer to WindowRec structure by
associated XID. Unlike dixLookupWindow(), this one works globally, instead
of just on one specific client, and it doesn't do any XACE calls.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since LogVMessageVerb() is now signal safe, we can use this one instead.
Leaving VErrorF() macro for backwards compat with drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Lots of logging functions, especially init and teardown aren't called
by any drivers/modules, so no need to keep them exported.
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>
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 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>
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>
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>
We don't have a standard protocol for enabling VRR yet, but some time ago an
ad-hoc had been made in the amdgpu driver (later also copied to modsetting),
which works by client setting the _VARIABLE_REFRESH window property.
The way it's currently done - driver is highjacking the X_ChangeProperty and
X_DeleteProperty request handlers - is pretty fragile, and is also a violation
of layers: drivers never should be twisted with core protocol details. (And in
the future, this should be done by some suitable extension).
Another problem is Xinerama: when it's enabled, this only works on the first
screen - the others won't ever see this signal, no matter on which one(s) the
Window is physically placed (for the wire protocol, all windows are on screen 0,
unless the client explicitly creates them on another one)
This commit adds a generic Screen proc for telling the DDX, whether the VRR mode
shall be changed (for now, it's only DISABLED and ENABLED). Drivers can hook into
here in order to receive this signal, w/o having to highjack any core request
handlers. Catching the property change is now entirely done in the DIX.
The (non-standard) status qou of (ab)using window properties is kept, but it's
now also easy to add a new signaling mechanism, in case a standard is agreed on.
Yet a quite naive implementation (eg. not acting on moving windows between screens),
but enough to fix the most pressing problems supporting extra screens in general,
as well as stopping the highjacking of core request handlers by drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of having the request handler ask for fd's one by one, just read them
all into a little array in ClientRec struct. And also automatically clean up
after request had been handled.
Request handlers need to set the entries to -1 if they shouldn't be closed
automatically.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Also dropping now obsolete SProcNoOperation().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XServer refuses the create windows with different color depth than the parent's,
just in the special case that neither border pixmap nor border pixel is given,
even if the screen supports it. (that's also one of the reasons why Xnest fails
to run with different color depths than the default one)
it really doesn't make sense to deny this, while it's allowed when having a
border color or pixmap set.
Fixes: ded6147b - R6.6 is the Xorg base-line
Closes:https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1644
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* unexport functions from dixgrab.h, that aren't used by any driver/module.
* add paremeter names to prototypes
* add doxygen-style documentation for all the prototypes
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Allow NULL parameters to be passed to FreeGrab(), so callers don't all
need to check on their own anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is only called once in the same source file, no external callers
at all. So, it doesn't need to be visible outside that file, and we can allow
the compiler to do whatever fancy optimizations it might wanna do.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This script used to generated xproto header as well as a piece of source
for initializing the builtin atoms in the Xserver (MakePredeclaredAtoms()).
At least with R6.6 baseline it didn't seem to be used anymore, and - at least
since the modularization - it's completely broken and useless.
Since we now have a new generator, running directly in the build process,
this ancient script can be dropped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function probably been (half?) auto generated somewhere back in the
dark ages (there're still remains of the former generator, which doesn't
work anymore, and hasn't been updated for ages). It's been added to SCM
with R6.6 baseline - and from that on manually maintained.
Adding a little generator to create source from "BuiltInAtoms" file,
directly in the build process.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Direct calls to ScreenRec->DestroyPixmap() blocks cleaning up the wrapping
jungle, so use the proper dix function instead.
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Clears warning from gcc 14.1:
../dix/resource.c: In function ‘HashResourceID’:
../dix/resource.c:691:44: warning: left shift of negative value
[-Wshift-negative-value]
691 | return (id ^ (id >> numBits)) & ~((~0) << numBits);
| ^~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1673>
No real harm, but clears warning from gcc 14.1:
../dix/property.c: In function ‘ProcListProperties’:
..//dix/property.c:605:27: warning: dereference of NULL ‘temppAtoms’
[CWE-476] [-Wanalyzer-null-dereference]
605 | *temppAtoms++ = pProp->propertyName;
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1673>
It shouldn't matter, since it would have a length of 0, but it
clears warnings from gcc 14.1:
../dix/property.c: In function ‘dixChangeWindowProperty’:
../dix/property.c:287:9: warning: use of possibly-NULL ‘data’ where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
287 | memcpy(data, value, totalSize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../dix/property.c:324:13: warning: use of possibly-NULL ‘data’ where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
324 | memcpy(data, value, totalSize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1673>
Clears warning from gcc 14.1:
../dix/dixfonts.c: In function ‘SetFontPath’:
../dix/dixfonts.c:1697:28: warning: use of uninitialized value ‘bad’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
1697 | client->errorValue = bad;
| ~~~~~~~~~~~~~~~~~~~^~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1673>
Clears warning from gcc 14.1:
../dix/dixfonts.c:1352:15: warning: use of uninitialized value ‘*c.data’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
1352 | free(c->data);
| ~^~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1673>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1345>
Enrico Weigelt, metux IT consult
Alan Coopersmith