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>
(cherry picked from commit ef77c486d5)
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>
(cherry picked from commit 0a7763bfce)
This script used to generated xproto header as well as a piece of source
for initializing the builtin atoms in the Xserver (MakePredeclaredAtoms()).
At least with R6.6 baseline it didn't seem to be used anymore, and - at least
since the modularization - it's completely broken and useless.
Since we now have a new generator, running directly in the build process,
this ancient script can be dropped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1670>
(cherry picked from commit 216fc6fe83)
These have been forgotten on some major cleanup back almost two decades ago.
(Daniel dropped a lot of dead code, which already had been removed earlier
but merged back accidentially).
Didn't look further back on where exactly they had become obsolete - being
unused for decades should be enough justification for dropping.
Fixes: 81913a1291
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1405>
(cherry picked from commit a1fa019012)
The cleanup function for GBM is called on the various error paths.
Once xwl_glamor_gbm_cleanup() has been called, GBM support is no longer
usable (and the corresponding data structures are freed), so there is
no way we can keep using GLAMOR after that point.
Make sure to explicitly disable GLAMOR support in that case, so we do
not crash later on trying to use GBM.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1768>
(cherry picked from commit e8784b7d89)
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>
(cherry picked from commit 45c1d22ff6)
Support for using inet_ntop() was originally added to support IPv6,
and only used for IPv6 addresses in AuthAudit(). Two decades later,
support for inet_ntop() is ubiquitous and OS'es have marked inet_ntoa()
as deprecated, so use the modern interface for IPv4 as well now.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1760>
(cherry picked from commit 6cc358dfb4)
Support for using getaddrinfo() was originally added to support IPv6,
and only used if IPv6 support was enabled. Two decades later, support
for getaddrinfo() is ubiquitous and OS'es have marked gethostbyname()
as deprecated, so use the modern interface whenever we can now.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1760>
(cherry picked from commit 2ffe0f8a35)
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>
(cherry picked from commit 92bcebfd7e)
Currently, Xwayland creates a pixmap backed by shared memory buffer as
soon as an X11 cursor is realized, which is destroyed when the cursor is
eventually unrealized.
If an X11 client is leaking cursors, Xwayland will be creating new
pixmaps continuously, which will eventually cause an error once the
limit is reached, and get Xwayland killed.
However, we do not need the shared memory buffer to stay around, we
already have the buffer retention mechanism which will take care of
keeping the buffer around until the Wayland compositor is done with it,
so we could just create and destroy the pixmap as needed when setting
the cursor.
That would not fix the leak in the X11 application, yet that would
mitigate the risk of Xwayland being killed by reaching the shared memory
limits, until the client itself reaches the limit of X11 resources.
v2: Don't increase the pixmap refcnt to destroy it just after (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <michel@daenzer.net>
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1773
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1754>
(cherry picked from commit 8707d2835c)
git supports ignoring specific revs during git blame, configured via
$ git config blame.ignoreRevsFile .git-blame-ignore-revs
Let's make this easier for developers to set up, starting with the
one massive coding style change commit.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1748>
(cherry picked from commit 298c5dcb02)
For the Wayland compositors who do not implement XkbBellNotifyMask but
support the Wayland protocol xdg-system-bell, use that to ring the
bell.
v2: Be more selective on the device, make sure it's a keyboard and it
has core events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1742>
(cherry picked from commit e4804d11e8)
If any dependency that a DDX requires is missing, the build of the DDX
will be automatically disabled, and the CI check will succeed.
We want the build to fail if any of the expected DDX cannot be built in
the CI, so let's force-enable them at build time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
v2: Use a variable for the DDX build args (Peter Hutterer
<peter.hutterer@who-t.net>)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1743>
(cherry picked from commit fbedb9b12b)
