Not used by any drivers, and shouldn't be used by them.
Needs to _X_EXPORT'ed, as long as glx is a separate module.
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>
Retrieves the ClientPtr for the owner of given resource.
This way reducing the sites directly accessing clients[] array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file had been changed manually several times or at least a decode now,
so the claim it's being auto-generated isn't valid anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file had been changed manually several times or at least a decode now,
so the claim it's being auto-generated isn't valid anymore.
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>
| ../glx/glxcmds.c: In function ‘xorgGlxMakeCurrent’:
| ../glx/glxcmds.c:621:24: warning: use of uninitialized value ‘status’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
| 621 | return status;
| | ^~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If this ever happens, we clearly have a bug, so print out proper warning,
instead of silently crashing the Xserver.
| ../glx/glxcmds.c: In function ‘validGlxFBConfigForWindow’:
| ../glx/glxcmds.c:127:16: warning: dereference of NULL ‘pVisual’ [CWE-476] [-Wanalyzer-null-dereference]
| 127 | if (pVisual->class != glxConvertToXVisualType(config->visualType) ||
| | ~~~~~~~^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
| ../glx/glxdricommon.c: In function ‘createModeFromConfig’:
| ../glx/glxdricommon.c:142:23: warning: dereference of possibly-NULL ‘config’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 142 | config->driConfig = driConfig;
Consumers can already handle returning NULL, so this seems the best compromise.
It will look like we don't have any modes at all. Certainly not nice, but at
least better than completely crashing the Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This warning is probably a false alarm, but it's trivial to fix.
| ../glx/createcontext.c: In function ‘__glXDisp_CreateContextAttribsARB’:
| ../glx/createcontext.c:172:24: warning: dereference of NULL ‘0’ [CWE-476] [-Wanalyzer-null-dereference]
| 172 | switch (attribs[i * 2]) {
| | ~~~~~~~^~~~~~~
The situation is too complex for the analyzer to handle:
(but also not immediately clear for the human reader)
* `attribs` is only NULL when req->numAttribs is 0
* in that case, the for loop is no-op, so `attribs` won't ever be deref'ed.
We can make it easier for both analyzer as well as human reader by just putting
the whole loop into an `if (req->numAttribs)` and assigning it inside there.
There shouldn't be any (practically measurable) extra cost.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external modules, so no need to keep it in public API.
Since it's used by DRI, still needs the _X_EXPORT flag, as long as DRI
is a dynamically loaded module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1790>
The OS abstraction isn't really the right place for those flags,
they are're probably better off in their corresponding extensions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1519>
Since LogMessageVerb() is now signal safe, we can use this one instead.
Leaving LogMessageVerbSigSafe() 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>
No need to have duplicated byte swapping macros in GLX for things that
the core alreay provides. Using core's macros is actually even easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
The reply length (in units as well as bytes) can safely be determined
at compile time, by using sizeof() operator. No need for unnecessarily
complicated shifting bits back and forth.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
The spec defines the reply as array of "CARD32", not "int". The latter
just accidentially has the same type (for now :o), but it's *semantically*
incorrect. Using CARD32 instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
Our array here really is fixed, but it's size is determined by a variable
(that's assigned a fix values), unncessarily making it a VLA (even making
it const doesn't change that), so giving false alarms when compiling w/
-Wvla or -Werror=vla.
Replacing the variable by #define trivially fixes this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
The reply struct's size can safely be determined by the sizeof()
operator, so no need for using an extra define here. Making the code
easier to read and also open the door for future convenience macros
that might determine the buffer size on their own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
Assigning structs at declaration is quicker to read/understand. No need
to support ancient compilers that couldn't do that, anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1665>
These files haven't been auto-generated, but instead manually changed for
at least over a decade now, so these warnings have become wrong.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1728>
It's just a local header, doing nothing more than including misc.h,
so we can just include misc.h directly and drop glxbyteorder.h
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1728>
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>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
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.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
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>
Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
With transition from autoconf to meson, these aren't actually supported
anymore, and re-adding it isn't planned. Thus the now dead code pathes
can be completely removed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1286>
The XSELINUX code will label resources at creation by checking the
access mode. When the access mode is DixCreateAccess, it will call the
function to label the new resource SELinuxLabelResource().
However, GLX buffers do not go through the XACE hooks when created,
hence leaving the resource actually unlabeled.
When, later, the client tries to create another resource using that
drawable (like a GC for example), the XSELINUX code would try to use
the security ID of that object which has never been labeled, get a NULL
pointer and crash when checking whether the requested permissions are
granted for subject security ID.
To avoid the issue, make sure to call the XACE hooks when creating the
GLX buffers.
Credit goes to Donn Seeley <donn@xmission.com> for providing the patch.
CVE-2024-0408
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
In CommonMakeCurrent() function, the tag of the old context is freed
before the new context is made current. This is problematic because if
the CommonMakeNewCurrent() function fails, the tag of the old context
ends up being removed, even though it is still active. This causes
subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to
generate a GLXBadContextTag error.
This change moves the function call that frees the old tag to a location
where the result of CommonMakeNewCurrent() call is known and it is safe
to free it.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
dasha_uwu
Herman Semenov
Enrico Weigelt, metux IT consult
Olivier Fourdan
Doğukan Korkmaztürk
Konstantin Kharlamov