Using the type "Bool", which is defined in Xdefs.h, therefore this
header should be include, so we don't need to rely on it being
included indirectly by somebody else.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's no use in redefining function names via preprocessor this
funny ways. Perhaps there once was back when that header used to
live outside the server tree, but that's decades ago.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of dozens of little WriteToClient() calls, collect the sub-replies in
a buffer and send the whole reply out at once. This also allows more upcoming
simplifications in the send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetGeometryReply,
called in two different cases, ProcXkbGetGeometry() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleGeometry() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetIndicatorMapReply,
called in two different cases, ProcXkbGetIndicatorMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleIndicatorMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetCompatMapReply,
called in two different cases, ProcXkbGetCompatMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleCompatMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetMapReply,
called in two different cases, ProcXkbGetMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For easier reading, move th sub-reply structs down to where they're used
first and use static initialization for the common fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move down the declaration of the reply struct, right before swapping and sending
and use static initialization.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code flow a bit easier to understand and allow further simplification
by now just having to write out one additional payload as one block.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Putting both payload pieces into one buffer, so it can be written out
with only one call.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's hard to see which fields of the xkbGetDeviceInfoReply struct it's
reading or writing, and that complicates further simplifications of the
caller. So instead let the caller pass in the relevant fields and do the
modifications on the reply structs on its own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A bit simplification in code flow.
The extra length check (did we write as much as intended?) isn't necessary,
since the buffer size is computed by the very same data before this
function is called.
Hint: the size computation must be done before calling this one, because
the reply might be encapsulated in another one (xkbGetKbdByName).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it a bit simpler and easier to read.
calloc() and WriteToClient() can handle zero lengths very well.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use static initializaton as much as possible and drop unnecessary
or duplicate zero assignments.
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>
No need to hard-crash the whole server if some strdup() calls failing,
those fields already may be NULL, so consumers can handle that situation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for RunXkbComp() to hard-crash (by calling XNFstrdup()) the server
if strdup() fails to allocate more memory - it's callers already handling
the situation gracefully.
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>
Even though the cases might be hypothetical, it's still better having some
tiny extra checks (that might be even optimized-out) and reduce the analyzer
noise a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In the rare case that NULL kbd is passed and also no components provided,
the corresponding error message code crashes on NULL pointer dereference.
| ../xkb/ddxLoad.c: In function ‘XkbDDXLoadKeymapByNames’:
| ../xkb/ddxLoad.c:393:25: warning: dereference of NULL ‘keybd’ [CWE-476] [-Wanalyzer-null-dereference]
| 393 | keybd->name ? keybd->name : "(unnamed keyboard)");
| | ~~~~~^~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The freeRules parameter is always set to TRUE, meaning always free the
XkbRF_RulesRec struct. Therefore also no need to clear out fields that
aren't going to be reused again, ever.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
Allow the compiler to figure out the most efficient way to do the
struct initialization, and a little improvement on code readability.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
The function is nothing more than a calloc() call, so we can spare
an actual function call here by making it static inline.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
Handles common case of allocating & copying string to temporary buffer
(cherry picked from xorg/lib/libxkbfile@8a91517ca6ea77633476595b0eb5b213357c60e5)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
Fixes formatting of negative numbers, so they don't show minus sign
after the decimal point.
(cherry picked from xorg/lib/libxkbfile@d2ec504fec2550f4fd046e801b34317ef4a4bab9)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
Passing a negative value in `needed` to the `XkbResizeKeyActions()`
function can create a `newActs` array of an unespected size.
Check the value and return if it is invalid.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: cond_const:
Checking "xkb->server->size_acts == 0" implies that
"xkb->server->size_acts" is 0 on the true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: buffer_alloc:
"calloc" allocates 8 bytes dictated by parameters
"(size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts)"
and "8UL".
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: var_assign:
Assigning: "newActs" = "calloc((size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts), 8UL)".
libX11-1.8.7/src/xkb/XKBMAlloc.c:815: assignment:
Assigning: "nActs" = "1".
libX11-1.8.7/src/xkb/XKBMAlloc.c:829: cond_at_least:
Checking "nCopy > 0" implies that "nCopy" is at least 1 on the
true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:830: overrun-buffer-arg:
Overrunning buffer pointed to by "&newActs[nActs]" of 8 bytes by
passing it to a function which accesses it at byte offset 15
using argument "nCopy * 8UL" (which evaluates to 8).
# 828|
# 829| if (nCopy > 0)
# 830|-> memcpy(&newActs[nActs], XkbKeyActionsPtr(xkb, i),
# 831| nCopy * sizeof(XkbAction));
# 832| if (nCopy < nKeyActs)
(cherry picked from xorg/lib/libx11@af1312d2873d2ce49b18708a5029895aed477392)
Signed-off-by: José Expósito <jexposit@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
If there was a previous radio_groups array which we failed to realloc
and freed instead, clear the array size in the XkbNamesRec.
Taken from xorg/lib/libx11@258a8ced681dc1bc50396be7439fce23f9807e2a
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
If XkbChangeTypesOfKey() is called with nGroups == 0, it will resize the
key syms to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value for nGroups,
this will cause a buffer overflow because the key actions are of the wrong
size.
To avoid the issue, make sure to resize both the key syms and key actions
when nGroups is 0.
CVE-2025-26597, ZDI-CAN-25683
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), leading to a heap overflow.
Fix the calculation in XkbSizeKeySyms() to match what kbWriteKeySyms()
does.
CVE-2025-26596, ZDI-CAN-25543
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the virtual mod name.
There's actually two issues in the code that can lead to a buffer
overflow.
First, the bound check mixes pointers and integers using misplaced
parenthesis, defeating the bound check.
But even though, if the check fails, the data is still copied, so the
stack overflow will occur regardless.
Change the logic to skip the copy entirely if the bound check fails.
CVE-2025-26595, ZDI-CAN-25545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
This (public) file isn't used by anybody outside Xserver tree
and doesn't contain anything useful anymore, so lets drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1729>
These are only used inside xkb/*, so no need to keep them exported.
Also replacing some macros by inline functions in order to improve
type-safety and debugging, and adding documentation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1729>
This function has only one caller in xkb.c, so no need to keep it exported,
can be moved over into xkb.c and made static.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1729>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
Consider the following keymap:
```xkb
xkb_keymap {
xkb_keycodes {
<compose> = 135;
};
xkb_symbols {
key <compose> {
[ SetGroup(group = +1) ]
};
};
};
```
When the user presses the compose key, the following happens:
1. The compositor forwards the key to Xwayland.
2. Xwayland executes the SetGroup action and sets the base_group to 1
and the effective group to 1.
3. The compositor updates its own state and sends the effective group,
1, to Xwayland.
4. Xwayland sets the locked group to 1 and the effective group to
1 + 1 = 2.
This is wrong since pressing compose should set the effective group to 1
but to X applications the effective group appears to be 2.
This commit makes it so that Xwayland completely ignores the key
behaviors and actions of the keymap and only updates the modifier and
group components in response to the wayland modifiers events.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1758>
Generating the modifier modmap, the helper function generate_modkeymap()
would check the entire range up to the MAP_LENGTH.
However, the given keymap might have less keycodes than MAP_LENGTH, in
which case we would go beyond the size of the modmap, as reported by
ASAN:
==ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1 at 0x5110001c225b thread T0
#0 0x5e7369393873 in generate_modkeymap ../dix/inpututils.c:309
#1 0x5e736930dcce in ProcGetModifierMapping ../dix/devices.c:1794
#2 0x5e7369336489 in Dispatch ../dix/dispatch.c:550
#3 0x5e736934407d in dix_main ../dix/main.c:275
#5 0x7e46d47b2ecb in __libc_start_main
#6 0x5e73691be324 in _start (xserver/build/hw/xwayland/Xwayland)
Address is located 0 bytes after 219-byte region
allocated by thread T0 here:
#0 0x7e46d4cfc542 in realloc
#1 0x5e73695aa90e in _XkbCopyClientMap ../xkb/xkbUtils.c:1142
#2 0x5e73695aa90e in XkbCopyKeymap ../xkb/xkbUtils.c:1966
#3 0x5e73695b1b2f in XkbDeviceApplyKeymap ../xkb/xkbUtils.c:2023
#4 0x5e73691c6c18 in keyboard_handle_keymap ../hw/xwayland/xwayland-input.c:1194
As MAP_LENGTH is used in various code paths where the max keycode might
not be easily available, best is to always use MAP_LENGTH to allocate the
keymaps so that the code never run past the buffer size.
If the max key code is smaller than the MAP_LENGTH limit, fill-in the gap
with zeros.
That also simplifies the code slightly as we do not constantly need to
reallocate the keymap to adjust to the max key code size.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1780
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1762>
Found by clang 13.0.1:
../xkb/xkbtext_priv.h:5:9: warning: '_XSERVER_XKB_XKBTEXT_PRIV_H' is used
as a header guard here, followed by #define of a different macro
[-Wheader-guard]
#ifndef _XSERVER_XKB_XKBTEXT_PRIV_H
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../xkb/xkbtext_priv.h:6:9: note: '_XSERVER_XKB_XKBTEXt_PRIV_H' is defined
here; did you mean '_XSERVER_XKB_XKBTEXT_PRIV_H'?
#define _XSERVER_XKB_XKBTEXt_PRIV_H
^~~~~~~~~~~~~~~~~~~~~~~~~~~
_XSERVER_XKB_XKBTEXT_PRIV_H
Fixes: 434044cb0 ("xkb: unexport functions from xkbtext.c")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1740>
The _XkbSetCompatMap() function attempts to resize the `sym_interpret`
buffer.
However, It didn't update its size properly. It updated `num_si` only,
without updating `size_si`.
This may lead to local privilege escalation if the server is run as root
or remote code execution (e.g. x11 over ssh).
CVE-2024-9632, ZDI-CAN-24756
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1733>
fix warning on unused variable:
> ../xkb/xkb.c:3576:18: warning: variable 'extDevReason' set but not used [-Wunused-but-set-variable]
> unsigned int extDevReason;
^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1426>
On NetBSD gives warning:
In file included from /usr/include/ctype.h:100,
from ../xkb/xkbtext.c:32:
../xkb/xkbtext.c: In function ‘XkbAtomText’:
../xkb/xkbtext.c:94:44: warning: array subscript has type ‘char’ [-Wchar-subscripts]
94 | if ((tmp == rtrn) && (!isalpha(*tmp)))
| ^
../xkb/xkbtext.c:96:31: warning: array subscript has type ‘char’ [-Wchar-subscripts]
96 | else if (!isalnum(*tmp))
| ^
../xkb/xkbtext.c: In function ‘XkbIMWhichStateMaskText’:
../xkb/xkbtext.c:470:43: warning: array subscript has type ‘char’ [-Wchar-subscripts]
470 | buf[len + 9] = toupper(buf[len + 9]);
| ^
../xkb/xkbtext.c: In function ‘XkbControlsMaskText’:
../xkb/xkbtext.c:532:43: warning: array subscript has type ‘char’ [-Wchar-subscripts]
532 | buf[len + 3] = toupper(buf[len + 3]);
| ^
../xkb/xkbtext.c: In function ‘XkbStringText’:
../xkb/xkbtext.c:563:22: warning: array subscript has type ‘char’ [-Wchar-subscripts]
563 | if (!isprint(*in)) {
| ^
../xkb/xkbtext.c:584:21: warning: array subscript has type ‘char’ [-Wchar-subscripts]
584 | if (isprint(*in))
| ^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1455>
* 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>
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.
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>
If XkbComputeGetGeometryReplySize() returns an error, the XkbGeometryRec won't
be freed, since we're bailing out too early and not calling XkbSendGeometry().
Having XkbSendGeometry() responsible for freeing that struct is unnecessarily
complicated anyways, so move that to ProcXkbGetGeometry() and do it also when
XkbComputeGetGeometryReplySize() failed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1622>
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 last use of struct '_SrvXkmInfo' was removed in
commit fbd7768946 ("XKB: Ditch XkbFileInfo").
Remove it.
The define MAX_TOC hasn't been used in this file since sometime
in the mid 90's; it's unused in version '1997/05/20 11:42:06'
but in '1.8 94/05/16 10:49:53' it's used in the definition
of _SrvXkmInfo.
Remove it.
Build tested.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1558>
Enrico Weigelt, metux IT consult
Alan Coopersmith
Martin Burggraf
José Expósito
Olivier Fourdan
Julian Orth
Matthieu Herrb
Dr. David Alan Gilbert