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>
These functions shouldn't be called by drivers or extensions, thus
shouldn't be exported. Also moving it to separate header, so the
already huge ones aren't cluttered with even more things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1334>
This function is only used inside the same .c file where it's defined,
no outside users, also not in drivers. Thus no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1468>
These functions are just used for reading auth file or calling xkbcomp while
dropping privileges, in case the Xserver is started as unprivileged user
with suid-root. Thus, shouldn't be used (and aren't used) by drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1370>
It's already defined in input.h, and that's where it belongs.
(we see from the header, which symbols belong to the module api)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1274>
This breaks the xf86-input-synaptics driver:
synaptics.c: In function 'clickpad_guess_clickfingers':
synaptics.c:2638:5: error: implicit declaration of function 'BUG_RETURN_VAL' [-Werror=implicit-function-declaration]
2638 | BUG_RETURN_VAL(hw->num_mt_mask > sizeof(close_point) * 8, 0);
This reverts commit 442aec2219.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1316>
No need to define XKBSRV_NEED_FILE_FUNCS, for about 15 years now
(since XKBsrv.h isn't used anymore), so drop it.
Fixes: e5f002edde
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Yet another step of uncluttering includes: move out the BUG_* macros
into a separate header, which then is included as-needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The XKM_OUTPUT_DIR folder by default is defined as ${datadir}/X11/xkb/compiled
and it is usually defined as /var/lib/xkb or %{_localstatedir}/lib/xkb by
distributions. If X is executed as non-root it won't have permissions to write
into that folder. If we fallback directly to /tmp we might get name collisions:
```
> Error: Cannot open "/tmp/server-10.xkm" to write keyboard description
> Exiting
```
Where the file /tmp/server-10.xkm already exists but is owned by another user
that previously executed X and had the display number 10. This is specially
problematic when exeuting Xvfb.
Before falling back to /tmp/ check first the XDG_RUNTIME_DIR.
This is to make sure the hardware gets the device states regardless
whether the internal state has changed or not, to overcome situations
that device LEDs are out of sync e.g. switching between VTs.
Signed-off-by: Yao Wei (魏銘廷) <yao.wei@canonical.com>
Unlike other elements of the keymap, this pointer was freed but not
reset. On a subsequent XkbGetKbdByName request, the server may access
already freed memory.
CVE-2022-4283, ZDI-CAN-19530
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
_XkbCheckRequestBounds assumes that from..to is at least one byte.
However, request strings can be empty, causing spurious failures in
XkbGetKbdByName calls. To avoid this, before checking bounds make
sure that the length is nonzero.
GetCountedString did a check for the whole string to be within the
request buffer but not for the initial 2 bytes that contain the length
field. A swapped client could send a malformed request to trigger a
swaps() on those bytes, writing into random memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Each string length field was accessed before checking whether that byte
was actually part of the client request. No real harm here since it
would immediately fail with BadLength anyway, but let's be correct here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This request accessed &stuff[1] before length-checking everything. The
check was performed afterwards so invalid requests would return
BadLength anyway, but let's do this before we actually access the
memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No validation of the various fields on that report were done, so a
malicious client could send a short request that claims it had N
sections, or rows, or keys, and the server would process the request for
N sections, running out of bounds of the actual request data.
Fix this by adding size checks to ensure our data is valid.
ZDI-CAN 16062, CVE-2022-2319.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XKB often uses a FooCheck and Foo function pair, the former is supposed
to check all values in the request and error out on BadLength,
BadValue, etc. The latter is then called once we're confident the values
are good (they may still fail on an individual device, but that's a
different topic).
In the case of XkbSetDeviceInfo, those functions were incorrectly
named, with XkbSetDeviceInfo ending up as the checker function and
XkbSetDeviceInfoCheck as the setter function. As a result, the setter
function was called before the checker function, accessing request
data and modifying device state before we ensured that the data is
valid.
In particular, the setter function relied on values being already
byte-swapped. This in turn could lead to potential OOB memory access.
Fix this by correctly naming the functions and moving the length checks
over to the checker function. These were added in 87c64fc5b0 to the
wrong function, probably due to the incorrect naming.
Fixes ZDI-CAN 16070, CVE-2022-2320.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Introduced in c06e27b2f6
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Most similar loops here use a pointer that advances with each loop
iteration, let's do the same here for consistency.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Sick of fighting vim and git from trying to add this fix with every
commit iteration...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This header merely defines the various protocol request handlers, so
let's rename it to something less generic and remove its include from
all the files that don't actually need it (which is almost all of them).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Let's move this to where all the other protocol handlers are.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
As can be seen in diff, nOut is always 0 here. The code was likely
copy-pasted from comparisons further below.
Fixes LGTM warning "Comparison is always false because nOut <= 0."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
As the comment says:
"symsPerKey/mapWidths must be filled regardless of client-side flags"
so we always have to call CheckKeyTypes which will notably fill mapWidths
and nTypes. That is needed for CheckKeySyms to work since it checks the
width. Without it, any request with XkbKeySymsMask but not
XkbKeyTypesMask will fail because of the missing width information, for
instance this:
XkbDescPtr xkb;
if (!(xkb = XkbGetMap (dpy, XkbKeyTypesMask|XkbKeySymsMask, XkbUseCoreKbd))) {
fprintf (stderr, "ERROR getting map\n");
exit(1);
}
XFlush (dpy);
XSync (dpy, False);
XkbMapChangesRec changes = { .changed = 0 };
int oneGroupType[XkbNumKbdGroups] = { XkbOneLevelIndex };
if (XkbChangeTypesOfKey(xkb, keycode, 1, XkbGroup1Mask, oneGroupType, &changes)) {
fprintf(stderr, "ERROR changing type of key\n");
exit(1);
}
XkbKeySymEntry(xkb,keycode,0,0) = keysym;
if (!XkbChangeMap(dpy,xkb,&changes)) {
fprintf(stderr, "ERROR changing map\n");
exit(1);
}
XkbFreeKeyboard (xkb, 0, TRUE);
XFlush (dpy);
XSync (dpy, False);
This had being going under the radar since about ever until commit
de940e06f8 ("xkb: fix key type index check
in _XkbSetMapChecks") fixed checking the values of kt_index, which was
previously erroneously ignoring errors and ignoring all other checks, just
because nTypes was not set, precisely because CheckKeyTypes was not called.
Note: yes, CheckKeyTypes is meant to be callable without XkbKeyTypesMask, it
does properly check for that and just fills nTypes and mapWidths in that
case.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
The previous if/else condition resulted in us always setting the key
type count to the current number of key types. Split this up correctly.
Regression introduced in de940e06f8Fixes#1249
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 446ff2d317 added checks to
prevalidate the size of incoming SetMap requests.
That commit checks for the XkbSetMapResizeTypes flag to be set before
allowing key types data to be processed.
key types data can be changed or even just sent wholesale unchanged
without the number of key types changing, however. The check for
XkbSetMapResizeTypes rejects those legitimate requests. In particular,
XkbChangeMap never sets XkbSetMapResizeTypes and so always fails now
any time XkbKeyTypesMask is in the changed mask.
This commit drops the check for XkbSetMapResizeTypes in flags when
prevalidating the request length.
I get this:
In function ‘TryCopyStr’,
inlined from ‘CopyISOLockArgs’ at ../xkb/xkbtext.c:875:9:
../xkb/xkbtext.c:720:13: warning: ‘tbuf’ may be used uninitialized [-Wmaybe-uninitialized]
720 | strcat(to, from);
| ^~~~~~~~~~~~~~~~
../xkb/xkbtext.c: In function ‘CopyISOLockArgs’:
<built-in>: note: by argument 1 of type ‘const char *’ to ‘__builtin_strlen’ declared here
../xkb/xkbtext.c:871:10: note: ‘tbuf’ declared here
871 | char tbuf[64];
| ^~~~
Just initialize tbuf so it definitely works.
xkb.c: In function ‘ProcXkbSetMap’:
xkb.c:2747:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
2747 | DeviceIntPtr master = GetMaster(dev, MASTER_KEYBOARD);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rework the function to use a single snprintf call instead of a mix of
strcpy/strcats. This now also appends a trailing slash where needed so we
don't rely on the build system to set this for us.
Also, since /tmp/ is the fallback and we never check if everything succeeded,
assert if we can't use /tmp/. This will never be triggered anyway, the only
caller to OutputDirectory() uses sizeof(PATH_MAX-sized array).
Follow-up from 6c51818a0f
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The xkb spec defines that the 7th element of the DeviceValuator key
action description is "valuator 2 value".
This error most likely was accidentally introduced as a copy-paste error
in edeb033f29.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Calling strlen on char[4] that does not need to contain '\0' is wrong and X
server may end up running into uninitialized memory.
In addition GCC 8 is clever enough that it knows that strlen on char[4] can
return 0, 1, 2, 3 or cause undefined behavior. With this knowledge it can
optimize away the min(..., 4). In reality it can cause the memcpy to be called
with bigger size than 4 and overflow the destination buffer.
Fixes: 83913de25d (xkb: Silence some compiler warnings)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/288
Signed-off-by: Matt Turner <mattst88@gmail.com>
Avoid out of bounds memory accesses on too short request.
ZDI-CAN 11572 / CVE-2020-14360
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
ZDI-CAN 11389 / CVE-2020-25712
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Resolves warning from Oracle Parfait static analyser:
Error: Uninitialised memory
Uninitialised memory variable [uninitialised-mem-var] (CWE 457):
Possible access to uninitialised memory referenced by variable 'mask'
at line 721 of xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'.
Path in callee avoiding write at line 720
mask allocated at line 718
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
CVE-2020-14361 ZDI-CAN 11573
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
CVE-2020-14345 / ZDI 11428
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This code block was moved from a function that returns 0 for failure to a
function that returns 0 for Success in commit
649293f6b6. Change the return value to
BadValue to match the other checks in _XkbSetMapChecks.
Set nTypes to xkb->map->num_types when XkbKeyTypesMask is not set, to
allow requests with the XkbKeyTypesMask flag unset in stuff->present to
succeed.
Fixes a potential heap smash when client->swapped is true, because the
remainder of the request will not be swapped after "return 0", but
_XkbSetMap will be called anyway (because 0 is Success).
Signed-off-by: Peter Harris <pharris@opentext.com>
The server swaps part of the request in _XkbSetMapChecks instead of
SProcXkbSetMap (presumably because walking the XkbSetMap request is hard,
and we don't want to maintain another copy of that code).
Swap the first time _XkbSetMapChecks is called, not the second time.
Signed-off-by: Peter Harris <pharris@opentext.com>
I can't think of a good reason why this would need to be deferred to the
work queue. When we get to this point we're never in the middle of
request processing, so we can't corrupt the event/reply stream.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Of the form:
../xkb/XKBGAlloc.c: In function ‘SrvXkbAddGeomKeyAlias’:
../xkb/XKBGAlloc.c:591:13: warning: ‘strncpy’ specified bound 4 equals destination size [-Wstringop-truncation]
strncpy(alias->real, realStr, XkbKeyNameLength);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is intentional; the code that reads from these fields never reads
more than 4 bytes anyway. Rephrase things in terms of memcpy so that's
clear. Obviously this is awful but in XKB awful is par.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
This fixes some “Conditional jump depends on uninitialized value(s)”
errors spotted by valgrind.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I don't know how many times I've had a broken server due to a bad
directory to xkbcomp, and only finding the whole path has shown me
where I went wrong.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
XKB stores some stuff in the ClientRec that, style-wise, should probably
be in a client private. vMinor tracks the client's idea of the XKB
minor version, but is never read, we can just nuke it. vMajor is only
used for a bug-compat workaround for X11R6.0-vintage clients. We're
only using though (1<<4) for xkbClientFlags in the protocol, so we can
pack that field down to a u8 and store the bug-compat flag there.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Generating strings for XKB data used a single shared static buffer,
which offered several opportunities for errors. Use a ring of
resizable buffers instead, to avoid problems when strings end up
longer than anticipated.
Reviewed-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
XkbStringText escapes non-printable characters using octal numbers. Such escape
sequence would be at most 5 characters long ("\0123"), so it reserves 5 bytes
in the buffer. Due to char->unsigned int conversion, it would print much longer
string for negative numbers.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
v2: Drop #ifndefs around the other two defines.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Declared as unsigned short in xkb/xkbAccessX.c.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-config.h.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
RedirectKey() action had been broken by commit 2e6190.
A dropped check caused over-intense autorepeat of keysyms enriched
with the action.
Previous to this commit, the check wrapped the entire switch() block,
which was dropped with the move to a separate function.
Restore the checking.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are two ways to separate multiple files in XKB include statements:
'+' will cause the later file to override the first in case of conflict,
while '|' will cause it augment it (this is done by xkbcomp). '!' is
unrelated here.
Currently, if someone tries to use '|' in a rule instead of '+', it
won't have any effect. Since '|' is practically never used, this wasn't
noticed.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Regression introduce by ac164e5887 which calls
XkbUpdateAllDeviceIndicators() with two NULL arguments. A few layers down into
the stack and we triggered a NULL-pointer dereference. In theory a NULL cause
is acceptable since we don't actually change modifier state here. Instead of
updating all places to check for NULL just set the cause to the client
request and go to the pub.
https://bugs.freedesktop.org/show_bug.cgi?id=96384
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The xserver generates the key repeat by itself.
But when used with another server processing inputs first (e.g. a
Wayland compositor), the other server may be busy dealing with some
other things and not queue up key release events in time.
Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
keypress event in the AccessX timer handler, so that the key repeat has
a chance to be denied if the server processing the input is not ready.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes the code more consistent with other versions of
out-of-queue event processing
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When NumLock is on and a new keymap is applied, the next modifier state
change will turn off that LED (but leave the state enabled). The cause
for this is a bit convoluted:
* the SLI explicitState is copied from the current state in
ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
* on the next modifier key press (e.g. Shift), XkbApplyState() calls into
XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any)
for the currently changed modifier. But it does so with a mask only for
the changed modifier (i.e. for Shift).
* XkbUpdateLedAutoState() calculates the state based on this mask and
ends up with 0 because we don't have a Shift LED and we masked out the
others.
* XkbUpdateLedAutoState() compares that state with the previous state
(which is still 0x2) and then proceeds to turn the LED off
This doesn't happen in the normal case because either the mask
encompasses all modifiers or the state matches of the masked-out
modifiers matches the old state.
Avoid this issue by forcing an SLI update after changing the keymap.
This updates the sli->effectiveState and thus restores everything to
happy working order.
https://bugzilla.redhat.com/show_bug.cgi?id=1047151
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
-Wlogical-op now tells us:
devices.c:1685:23: warning: logical ‘and’ of equal expressions
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Wrong use of the mask here caused a beep whenever a key was rejected but
also when it was released after being accepted. Fix the mask to check
for the correct enabled controls.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Globally replace #ifdef and #if defined usage of 'sun' with '__sun'
such that strict ISO compiler modes such as -ansi or -std=c99 can be used.
Signed-off-by: Richard PALO <richard@NetBSD.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Add a new event source type for keypress events synthesised from focus
notifications (e.g. KeymapNotify from the parent server, when running
nested). This is used to keep the keys-down array in sync with the host
server's, without sending actual keypress events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a flag to DeviceEvents, giving the source of the event. Currently
this only supports a 'normal' flag, but will be used later to add a
'focus-in' flag, noting events synthesised from key/button arrays on
focus-in notifications.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the giant state machine which maps from a key action to actually
running the filters into a separate function, to be used when adding
KeyFocusIn.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With this change, when a key mapped to an action to emulate mouse button
presses and releases is held down, other keys pressed during that time are
still processed normally. This is a prerequisite for proper support of
ISOLock.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The autorepeat for these actions was not correctly implemented, as the key
repeat would be mistakenly interpreted as key releases. Rather than fixing
this, this change simply disables autorepeat for Set/Lock actions, for two
reasons:
- Autorepeating Set/Lock keys make complicate the interactions of actions.
- Autorepeating Set/Lock keys have no apparent benefit, but hurt in the real
world for layouts such as de(neo): Neo has a Level5 shift on the LSGT key,
and a Level5 lock on Level5 of the same key. This is unusable if LSGT
autorepeats. However, disabling autorepeat for key LSGT completely is not
ideal for users that have a "usual" layout besides Neo, where LSGT carries
symbols.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Ensure that the given strings length in an XkbSetGeometry request remain
within the limits of the size of the request.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The XkbSetGeometry request embeds data which needs to be swapped when the
server and the client have different endianess.
_XkbSetGeometry() invokes functions that swap these data directly in the
input buffer.
However, ProcXkbSetGeometry() may call _XkbSetGeometry() more than once
(if there is more than one keyboard), thus causing on swapped clients the
same data to be swapped twice in memory, further causing a server crash
because the strings lengths on the second time are way off bounds.
To allow _XkbSetGeometry() to run reliably more than once with swapped
clients, do not swap the data in the buffer, use variables instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When _XkbCheckAtoms returns NULL for an error, it always sets the
error return code, but GCC can't figure that out, so just initialize
the local variable, 'bad', in _XkbSetNamesCheck to eliminate the warning.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
XkbInterestPtrs are created by clients that already exist, meaning,
clients that have already had ProcVector installed as something other
than InitialProcVector.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Check the return values from fread to make sure the elements are
actually getting read from the file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This was the wrong fix to the problem, and it triggered a change in XKB
behavior: previously a button event would unlock a latched modifier, now it
doesn't anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=73155
Note that the new behavior is is strictly spec compliant but we've had the
other behavior for a long time so we shouldn't break it.
The bug this patch originally fixed was a null-pointer dereference when
releasing button events on server shutdown. This was addressed by the commit
below, so the need for this patch has gone away anyway.
commit 3e4be4033a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jan 25 11:47:32 2013 +1000
dix: when shutting down slave devices, shut down xtest devices last
This reverts commit 2decff6393.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Removed in d35a02a767, tigervnc 1.2.80 and
xf86-video-nested need it for now.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Helper function to return a default map if the keymap compilation failed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This provides a callback to write to xkbcomp's buffer once everything is
prepared.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This will also make it useful for cases when we have a new keymap to
apply to a device but don't have a source device.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Whenever the master changes, push the locked modifier state to the attached
slave devices, then update the indicators. This way, when NumLock or CapsLock
are hit on any device, the LED will light up on all devices. Likewise, a new
keyboard attached to a master device will light up with the correct
indicators.
The indicators are handled per-keyboard, depending on the layout, i.e. if one
keyboard has grp_led:num set, the NumLock LED won't light up on that keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Just forcing everything to const char* is not helpful, compiler warnings are
supposed to warn about broken code. Forcing everything to const when it
clearly isn't less than ideal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If the -ardelay or -arinterval options have no argument, there's no
point trying to read it.
See
http://www.forallsecure.com/bug-reports/feb3db57fc206d8df22ca53a6907f74973876272/
Reported-by: Alexandre Rebert <alexandre@cmu.edu>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If drivers supply incorrect values don't just quietly return False, spew to
the log so we can detect what's going on. All these cases are driver bugs
and should be fixed immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
InitPointerClassDeviceStruct/InitKeyboardDeviceStruct allocate a
proximity/focus class, respectively. If a driver calls
InitFocusClassDeviceStruct or InitProximityClassDeviceStruct beforehand,
the previously allocated class is overwritten, leaking the memory.
Neither takes a parameter other than the device, so we can simply skip
initialising it if we already have one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
==2547== 1 bytes in 1 blocks are still reachable in loss record 1 of 111
==2547== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2547== by 0x64D1551: strdup (strdup.c:43)
==2547== by 0x4802FB: Xstrdup (utils.c:1113)
==2547== by 0x585B6C: XkbSetRulesUsed (xkbInit.c:219)
==2547== by 0x58700F: InitKeyboardDeviceStruct (xkbInit.c:595)
==2547== by 0x419FA3: vfbKeybdProc (InitInput.c:74)
==2547== by 0x425A3D: ActivateDevice (devices.c:540)
==2547== by 0x425F65: InitAndStartDevices (devices.c:713)
==2547== by 0x5ACA57: main (main.c:259)
and a few more of the above.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The main problem this patch addresses is that if a latch is put on
multi-level key with a Latch/Lock/Set, it is possible that after all
keys are released, still base modifiers are set, which typically will
make the keyboard unusable. To see how it happens (without the patch),
assume that key AltGr sets Mod5 when pressed by itself, and latches Mod3
when pressed together with Shift. Now press Shift, then AltGr and
release both keys in reverse order. Mod3 is now latched, and the
LatchMods filter remains active as the second filter. Now press AltGr;
Mod5 base modifier gets set, and the SetMods filter will become active
as the first filter. Release AltGr: First, the SetMods filter will set
clearMods to Mod5, then the LatchMods filter will overwrite clearMods
with Mod3. Result: the Mod5 base modifier will remain set. This
example becomes practically relevant for the revised German standard
layout (DIN 2137-1:2012-06).
Other changes implement the latch behaviour more accurately according to
the specification. For example, releasing a modifier latching key can
at the same time clear a locked modifier, promote another modifier that
is latched to locked, and latch a third modifier. Overall, what the
code does should be straightforward to compare what the XKB protocol
specification demands, see the table in section 6.3.
Finally, releasing a key no longer cancels a latch that has not become
pending yet. In my opinion, the specification is not clear; it speaks
of "operating" a key, which the patch effectivly interprets as "press"
rather than "press or release". From my experience, using the latter
interpretation makes latches on higher levels practically unusable. In
the example given above, one would have to release AltGr always before
Shift to get the Mod3-Latch. The practical relevance of latches on
higher levels is once more given by the revised German standard layout.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Xlib doesn't use this value (it computes it from the reply length
instead) which is why nobody has noticed yet. But the spec
http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html
says that it should be set.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xkb.c: In function '_XkbSetNamesCheck':
xkb.c:3987:18: warning: variable 'names' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
The redirect and the message action filter functions implicitly assumed that
when they receive an event for the same keycode they were activated for, that
this is the a release of the key that activated the filter. This is not true
if the key autorepeats. Due to the incorrect assumption, the effective key
repeat rate was effectively halved.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The base group is not brought into range and, therefore, using it as an array
index crashed the X server. Also, at this place, we should ignore locked
groups, but not latched groups. Therefore, use sum of base and latched groups,
brought into range.
Reproducible with:
key <FK07> {
type= "ONE_LEVEL",
symbols[Group1]= [ NoSymbol ],
actions[Group1]= [ LatchGroup(group=-1, clearLocks) ]
};
And hitting F7 will exceed the group level and access arbitrary memory.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The formatter confused address operators preceded by casts with
bitwise-and expressions, placing spaces on either side of both.
That syntax isn't used by ordinary address operators, however,
so fix them for consistency.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Regression introduced by commit 2decff6393
xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP
XTest buttons must be released when a physical button is released. This was
fixed in 1432785839, but
2decff6393 changed a condition that this code
didn't get triggered anymore.
"dev" for pointer events is now always the VCP which doesn't have a xkbi
struct. So move this condition out and always trigger the XTest released for
button events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Frank Roscher <Frank-Roscher@gmx.net>
eventType is set for the type that triggered a XkbControlsNotify event.
Technically, SlowKeys is triggered by a timer which doesn't have a matching
core event type. So we used to use 0 here.
Practically, the timer is triggered by a key press + hold and cancelled when
the key is released before the timeout expires. So we might as well set
KeyPress (keycode) in the ControlsNotify to give clients a chance to differ
between timer-triggered SlowKeys and client-triggered ones.
This is a chance in behaviour, though I suspect with little impact.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
No-one uses this - not xkbcomp, not GNOME, not KDE. The preferred way
to deal with component listing (which gives you RMLVO rather than
KcCGST) is to use the XML files on the client side.
Indeed, a couple of hours after making this commit, it emerged that all
*.dir files built with xkbcomp 1.1.1 (released two years ago) and later
have been catastrophically broken and nearly empty. So I think that's
reasonable proof that no-one uses them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rules which match star (*) and option, like one below, should be applied
layout[2] option = symbols
* misc:typo = +typo(base)
This is port of patch from #19563 (https://bugs.freedesktop.org/19563)
because here we have own copy of maprules.c
X.Org Bug 25873 <http://bugs.freedesktop.org/show_bug.cgi?id=25873>
Signed-off-by: Alexey Ten (Lynn) <alexeyten@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For button release events, the current code picks the VCK. Because that has
a XKB struct, it thinks this is a PointerKeys event and proceeds to send the
release event through the XTest pointer. That has no effect in normal
operation as the button is never down and an attempt is silently discarded
(normal event processing continues with the VCP).
On server shutdown, the XTest device is already removed, leading to a
null-pointer derefernce when the device is checked for whether buttons are
down (XkbFakeDeviceButton → button_is_down(xtest pointer)).
The current state has only worked by accident, the right approach here is to
handle the VCP's event as such and not switch to the keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Popen and Pclose are never used on Windows, so don't bother to even
try to define them.
System(s) was defined as system(s), but the two users of that
function are in xkb, which carefully redefines that as
Win32System. Move Win32System and Win32TempDir to os/utils.c, renaming
Win32System to be just System, which simplifies the xkb code
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
These codepaths were never called by anyone. Shame there weren't more
of them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Create extinit.h (and xf86Extensions.h, for Xorg-specific extensions) to
hold all our extension initialisation prototypes, rather than
duplicating them everywhere.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
Casting return to (void) was used to tell lint that you intended
to ignore the return value, so it didn't warn you about it.
Casting the third argument to (char *) was used as the most generic
pointer type in the days before compilers supported C89 (void *)
(except for a couple places it's used for byte-sized pointer math).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
Slow keys are enabled when the XKB AccessX features are generally enabled
(ctrls->enabled_ctrls & XkbAccessXKeysMask) and either shift key is held for
8 seconds. For the unsuspecting user this appears as if the keyboard
suddenly stops working.
Print a warning to the log, so we can later tell them "told you so".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
The current code seems to skip syms with width less than
type->num_levels when calculating the total size for the new
size_syms. This leads to less space being allocated than necessary
during the next phase, which is to copy over the syms to the new
location. This results in an overflow leading to a crash.
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When redirect actions are used with Gtk3, Gtk3 complained about
events not holding a GdkDevice. This was caused by device IDs
not being set for redirect actions.
More seriously, Gtk3 did not receive state changes redirect
actions might specify. This was because event_set_state in
dix/inpututils.c accesses the prev_state field, but the changes
for the redirect action were only put into the state field.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the typedef wasn't perfect, indent would get confused and change:
foo = (SomePointlessTypedef *) &stuff[1];
to:
foo = (SomePointlessTypedef *) & stuff[1];
Fix this up with a really naïve sed script, plus some hand-editing to
change some false positives in XKB back.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When a key to which a message action is mapped is held down, presses of
other keys were not registered.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main body of this function is an if { } else if { } pair of blocks.
Previously there was int button at the top level scope which is used
only in the first block, and a redeclaration of int button inside the
second block. Since there's no overlap in the code paths for the
two uses of button, move the one from the outer block into the first
block to help the programmer more quickly determine they are unrelated
usages, and to silence the gcc warning of:
xkbActions.c: In function '_XkbFilterDeviceBtn':
xkbActions.c:999:6: warning: declaration of 'button' shadows a previous local
xkbActions.c:955:6: warning: shadowed declaration is here
For consistency, move DeviceIntPtr dev declarations as well that are
used in the same way.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Variable is already defined outside the outer if statement, and
there's no need to redefine inside the if statement.
No point in setting sli before if (dev->kbdfeed->xkb_sli==NULL)
check - if check is true, we immediately set it, if check is false,
we immediately return without further reference or use of it.
The one thing we do with it inside the inner if statement is store
an allocation in it for a brief moment before writing to the final
destination, which is immediately returned to the caller.
In short, there's no benefit to the variable at all in this block,
it just gives the optimizer more code to figure out how to omit.
Fixes gcc warning:
xkbLEDs.c: In function 'XkbFindSrvLedInfo':
xkbLEDs.c:683:19: warning: declaration of 'sli' shadows a previous local
xkbLEDs.c:679:18: warning: shadowed declaration is here
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Stop temporarily storing a pointer to a constant literal string
in a char *, just to strdup it a few lines later.
Fixes gcc -Wwrite-strings warnings:
xkbInit.c: In function 'XkbGetRulesDflts':
xkbInit.c:121:38: warning: assignment discards qualifiers from pointer target type
xkbInit.c:123:23: warning: assignment discards qualifiers from pointer target type
xkbInit.c:125:24: warning: assignment discards qualifiers from pointer target type
xkbInit.c:127:25: warning: assignment discards qualifiers from pointer target type
xkbInit.c:129:25: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Cleans up around 120 warnings from this set
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Instead of using sprintf to copy a static string to a local buffer,
just to pass it to TryCopyStr, pass the static string to TryCopyStr
directly, as is already done in other parts of this code.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This batch is the straightforward set - others are more complex and
need more analysis to determine right size to pass.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Also removes even more unnecessary use of variable assignment inside
function arguments.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
As long as we're carrying around a compatibility copy in os/strl*.c,
might as well use them.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Wherever it's obvious which device we need (keyboard or pointer), use
GetMaster() instead of GetPairedDevice(). It is more reliable in actually
getting the device type we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
When built for native Win32, pipe() & fork() aren't available, so we
use a tempoary file and system() to invoke xkbcomp
Ensure the temporary file is always removed. It was only being removed
on most errors, not on success :S
Also fix a couple of warnings which occur when built with WIN32 defined
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
These flags are required by the XKB spec section 6.3.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes Sun compiler warning:
"xkbAccessX.c", line 128: warning: implicit function declaration: init_device_event
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Caught during review of e095369bf.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Swapping the wrong size was never caught because swap{l,s} are macros.
It's clear in the case of Xext/xres.c, that the author believed
client_major/minor to be CARD16 from looking at the code in the first
hunk.
v2: dmx.c fixes from Keith.
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Also, fix whitespace, mainly around
swaps(&rep.sequenceNumber)
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
getevents.c already had that function, but XKB was manually initializing it,
causing bugs when the event structure was updated in one place but not the
other.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bugfix for broken xkbcomp: if we encounter an XFree86Private action with
Any+AnyOfOrNone(All), then we skip the interp as broken. Versions of
xkbcomp below 1.2.2 had a bug where they would interpret a symbol that
couldn't be found in an interpret as Any. So, an
XF86LogWindowTree+AnyOfOrNone(All) interp that triggered the PrWins
action would make every key without an action trigger PrWins if libX11
didn't yet know about the XF86LogWindowTree keysym. None too useful.
We only do this for XFree86 actions, as the current XKB dataset relies
on Any+AnyOfOrNone(All) -> SetMods for Ctrl in particular.
See xkbcomp commits 2a473b906943ffd807ad81960c47530ee7ae9a60 and
3caab5aa37decb7b5dc1642a0452efc3e1f5100e for more details.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
That one was missing _XkbKSLower:
XK_kra: U+0138 LATIN SMALL LETTER KRA
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Those ones were getting _XkbKSLower for no reasons:
XK_ogonek: U+02DB OGONEK
XK_doubleacute: U+02DD DOUBLE ACUTE ACCENT
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
That one was missing _XkbKSLower:
XK_ssharp: U+00DF LATIN SMALL LETTER SHARP S
That one was getting _XkbKSLower for no reasons:
XK_division: U+00F7 DIVISION SIGN
For reference, XK_multiply was already excluded from the _XkbKSUpper
check, it's no big surprise XK_division has to be excluded from the
_XkbKSLower check.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Spotted by -Wlogical-op:
| CC xkbfmisc.lo
| xkbfmisc.c: In function '_XkbKSCheckCase':
| xkbfmisc.c:104:3: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
| xkbfmisc.c:118:3: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
A quick look at the keysymdef.h file (from xproto) suggests the
implementor chose to use interval checks to determine the case, but
since lines weren't sorted by codepoints, checks were quite wrong.
Implement _XkbKSUpper/_XkbKSLower checks based on a grep for
CAPITAL/SMALL (respectively) on the Latin 8 part of the said file.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
EventListPtr is a relic from pre-1.6, when we had protocol events in the
event queue and thus events of varying size.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Due to an unfortunate sense inversion incident while switching from a
if (foo) { ... } to if (!foo) continue; style in f06a9d, we punished any
client who attempted to use XKB to restrict the MapNotify events they
wanted by sending them exactly the events they _didn't_ want, and
nothing else.
NewKeyboardNotifies (coming from a client setting the map with an XKB
request, when switching between master devices, etc) weren't affected,
but this would impact anyone using xmodmap-style core requests. Could
explain a fair bit.
Clarified the comments while I was at it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We were using XIShouldNotify(client, device) as a test for whether or
not to send XKB map/state/etc changed events, which limits it to only
sending events for the current ClientPointer/ClientKeyboard for that
client. While this makes perfect sense for core events (e.g.
MappingNotify), XKB events carry a device ID, so are safe to send to all
clients for all devices.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Enrico Weigelt, metux IT consult
Julian Orth
Olivier Fourdan
Alan Coopersmith
Matthieu Herrb
Dr. David Alan Gilbert
Peter Hutterer
Alessandro Bono
Benno Schulenberg
Yao Wei
FeepingCreature
Konstantin Kharlamov
Samuel Thibault
Povilas Kanapickas
Ray Strode
Adam Jackson
Michal Srb
Ignacio Casal Quinteiro
Peter Harris
Dave Airlie
Samir Benmendil
Giuseppe Bilotta
Eric Anholt
Daniel Martin
Keith Packard
Matt Turner
Mihail Konev
Ran Benita
Richard PALO
Daniel Stone
Andreas Wettstein
Kristian Høgsberg
Rui Matos
Julien Cristau
Yaakov Selkowitz
Daniel Stone
Alexey Ten (Lynn)
Siddhesh Poyarekar
Michal Suchanek
Colin Harrison
Cyril Brulebois