|
4823838f
|
2023-07-04T09:23:23
|
|
Move STRINGIFY to utils.h and add STRINGIFY2
|
|
4a576ab1
|
2021-08-31T21:50:52
|
|
x11: try to fix crash in xkb_x11_keymap_new_from_device error handling
In 1b3a1c277a033083fee669e92c8cad862716ebd1 we changed the error
handling in this code to not bail out immediately but only after
everything has been processed, to simplify the code. But I suspect the
code isn't prepared for this and that's what causing the crash reported
in the issue.
Bring back the short-circuit error handling which would hopefully fix
such crashes.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/252
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
4e361712
|
2021-08-31T22:03:03
|
|
x11: stylistic fixes
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
29af25ea
|
2021-04-07T10:47:15
|
|
x11: fix xkb_x11_keymap_new_from_device failing when a level name is empty
The numpad:mac option doesn't specify a name for the first level:
// On Mac keypads, level 1 and 2 are swapped.
partial xkb_types "mac" {
type "KEYPAD" {
modifiers = None;
map[None] = Level2;
level_name[Level2] = "Number";
};
include "extra(keypad)"
};
This means the atom for level name is XCB_ATOM_NONE. We tried to get its
name, which fails. This regressed in 40c00b472144d1684d2fb97cafef39.
Instead, translate it to XKB_ATOM_NONE, same as the previous behavior.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/229
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
62b5b4a1
|
2021-03-28T13:01:57
|
|
x11: fix comparison of integer expressions of different signedness
src/x11/keymap.c:980:26: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
980 | for (size_t i = 0; i < length; i++) {
| ^
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
21c864cc
|
2021-03-09T09:44:25
|
|
Inline x11_atom_interner_adopt_atoms() into callers
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
c0339701
|
2021-03-07T09:24:40
|
|
Save another GetAtomName round trip
Both get_atom_name() and the new atom interner required a round trip. Move
get_atom_name() into the atom interner to save one more round trip. This brings
xkb_x11_keymap_new_from_device() down to two round trips, which is the minimum
possible number.
(Also, I think the new code in keymap.c is more readable than the mess I
previously created)
With this last commit in the series, this definitely:
Fixes: https://github.com/xkbcommon/libxkbcommon/pull/217
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
c8efc3d6
|
2021-03-07T08:48:34
|
|
Also batch the XKB GetNames request
This gets rid of another round trip.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
599064cf
|
2021-03-07T08:46:19
|
|
Also batch the XKB-GetMapMap request
This gets rid of one more round trip.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
1b3a1c27
|
2021-03-07T08:42:54
|
|
Remove three more round trips
There are a number of XKB requests needed to request all the information from
the X11 server. So far, the code was sending one request and waiting for the
reply. This commit starts batching the request so that we get multiple replies
with one round trip.
This removes three round trips.
Only the simple requests are converted. get_map() and get_names() use some
bitmasks that are needed for both the request and the reply. These will be dealt
with separately.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
b9707c1d
|
2021-03-07T08:01:49
|
|
Save three more round trips in xkb_x11_keymap_new_from_device()
Instead of asking for an atom name and waiting for the reply four times, this
now sends four GetAtomName requests and waits for all the replies at once. Thus,
this saves three round trips.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
40c00b47
|
2021-03-07T07:42:28
|
|
xkb_x11_keymap_new_from_device: Less X11 round-trips
On my system, calling xkb_x11_keymap_new_from_device() did 78 round trips to the
X11 server, which seems excessive. This commit brings this number down to about
9 to 10 round trips.
The existing functions adopt_atom() and adopt_atoms() guarantee that the atom
was adopted by the time they return. Thus, each call to these functions must do
a round-trip. However, none of the callers need this guarantee.
This commit makes "atom adopting" asynchronous: Only some time later is the atom
actually adopted. Until then, it is in some pending "limbo" state.
This actually fixes a TODO in the comments.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/216
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
|
ac6cd20c
|
2020-11-23T18:49:49
|
|
x11: fix type level names missing
When reading the keymap, the level names would get discarded.
Regressed in 26453b84732da870f5695ee347970b337cfea9c1.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
4aed3c68
|
2020-11-23T18:24:52
|
|
x11/keymap: fix case with no actions
Possible regression in f41e609bbea8447fc82849a1a6ea0d116189f2f8 (not
confirmed yet).
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
1bd3b3c7
|
2020-11-19T00:28:37
|
|
x11: cache X11 atoms
On every keymap notify event, the keymap should be refreshed, which
fetches the required X11 atoms. A big keymap might have a few hundred of
atoms.
A profile by a user has shown this *might* be slow when some intensive
amount of keymap activity is occurring. It might also be slow on a
remote X server.
While I'm not really sure this is the actual bottleneck, caching the
atoms is easy enough and only needs a couple kb of memory, so do that.
On the added bench-x11:
Before: retrieved 2500 keymaps from X in 11.233237s
After : retrieved 2500 keymaps from X in 1.592339s
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
f41e609b
|
2020-11-20T12:45:42
|
|
x11: eliminate slow divisions
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
40aab05e
|
2019-12-27T13:03:20
|
|
build: include config.h manually
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
34122f9f
|
2019-12-27T12:34:49
|
|
utils: use MIN/MAX instead of min/max
min/max symbols conflict on some systems (msvc), so just use the macros.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
a9ace75f
|
2018-08-18T14:28:15
|
|
x11: fix undefined behavior when copying the coordinates of ptr movements actions
Left shift of a negative integer. For some reason the protocol
representation here got really botched (in the spec it is just a nice
and simple INT16).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
767fa86d
|
2017-12-21T14:18:07
|
|
Convert http:// -> https:// where possible
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4fccdee3
|
2017-12-18T16:41:21
|
|
x11: check and document the correct range of device IDs
The actual value is 127, not 255.
https://bugs.freedesktop.org/show_bug.cgi?id=104321
Reported-by: Gatis Paeglis <gatis.paeglis@qt.io>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
daebdb5e
|
2017-07-31T10:18:54
|
|
x11/keymap,test/interactive-evdev: fix a couple of clang-analyzer warnings
From my analysis these values cannot be null, but the analyzer cannot
see this. So assert it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
56de0115
|
2014-08-09T22:41:01
|
|
x11/keymap: handle private actions
Previously we treated them as NoAction().
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
f00e779a
|
2014-08-08T17:21:28
|
|
x11/keymap: be more defensive about the number of modifiers
There can be at most 16 vmods, and we rely on the facts that #vmods +
NUM_REAL_MODS (8) <= XKB_MAX_MODS (32) when accessing keymap->mods.mods.
But msb_pos() can potentially return up to #vmods = 32 if the server is
malicious, so we need to truncate it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
01753c04
|
2014-08-08T16:36:42
|
|
x11/keymap: don't forget to add the vmod offset in get_vmods
The first 8 modifiers in keymap->mods are the real modifiers; the virtual
modifiers are then at slots 8-24. But XkbGetMap's virtualMods mask
starts the virtual modifiers at zero, so we need to add an offset (like
we do correctly in get_vmod_names()).
https://github.com/xkbcommon/libxkbcommon/issues/9
Reported-by: @rtcm
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9c30d6da
|
2014-06-15T15:30:51
|
|
x11: don't iterate on empty batches
If count % SIZE == 0 we did a useless iteration where start==stop. It's
harmless but strange, so don't do that.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
67d884ec
|
2014-06-01T15:24:10
|
|
Remove unnecessary !!(expressions)
_Bool already does that.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e3f751be
|
2014-05-14T11:44:29
|
|
x11: fix out-of-bounds access in adopt_atoms() error handling
Two problems:
- `j` can be >= `SIZE`, and needs to be wrapped like in the rest of the
code.
- `cookies[j % SIZE]` is not initialized if there's no atom in `from[j]`.
The is manifested when:
- We've already gone through one batch (>= 128 atoms) (in fact this
cannot happen in call to `adopt_atoms` in the current code).
- An XCB request failed in the middle of a batch.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9014cf8c
|
2014-04-22T13:15:21
|
|
keymap, keycodes, compat: don't use darray for LEDs
Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
787faf36
|
2014-04-22T12:23:36
|
|
keymap: don't use darray in xkb_mod_set
Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ca3170ad
|
2013-02-08T13:09:33
|
|
Add struct xkb_mod_set
The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3c14d233
|
2014-03-06T13:43:02
|
|
x11: relax XkbGetNames requirements
It is valid for a keymap to not have key aliases, group names and
various other things. But the current test requires all of them to be
present in the reply, which causes us the fail on such keymaps (as the
XQuartz one).
Instead, require only what we really need. The virtual-mods names may
not be strictly required, but it seems safer to leave it in for now.
https://bugs.freedesktop.org/show_bug.cgi?id=75798
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
18191702
|
2014-02-16T10:59:42
|
|
keymap: change action flag NO_ACCEL -> ACCEL
It's easier to deal with, but we need to set it as "factory default".
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
af261cb6
|
2014-02-16T10:22:32
|
|
action: fix SwitchScreen "same" field handling
This used to *unset* a flag called "SwitchApplication"; we changed the
flag to "same" but forgot to switch the cases.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8be2608a
|
2014-02-09T18:02:11
|
|
x11: don't trust keycode before testing its range
The assert is not very useful access the key just before.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d53eef0d
|
2014-02-09T10:27:45
|
|
x11: add 0 < ctrls->numGroups <= 4 assertion
This only happens if something is wrong in the server; a valid keymap
cannot be had in any case.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
973b8fd4
|
2014-02-08T16:40:20
|
|
api: deprecate XKB_MAP_COMPILE_PLACEHOLDER, and use KEYMAP instead of MAP
The PLACEHOLDER was not meant to be used, but c++ doesn't like passing 0
to enums, so it was used. For this reason we add all the NO_FLAGS items,
so the PLACEHOLDER shouldn't be used anymore.
Second, XKB_MAP is the prefix we used ages ago, KEYMAP is the expected
prefix here. So deprecate that as well.
The old names may still be used through the xkbcommon-compat.h header,
which is included by default (no need to include directly).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8cc9434f
|
2014-02-08T16:38:18
|
|
x11: make sure not to use compat header
src/keymap.h already defines the necessary header guard, so just reverse
the include order.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ac42103b
|
2014-02-08T16:25:22
|
|
x11: make some #defines unsigned
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8fcb44b8
|
2014-02-08T16:18:16
|
|
x11: fix truncation of xkb controls mask off the wire
It's uint32_t, not uint16_t, so we were losing flags (not that it
matters in this case).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
f5465b56
|
2014-02-08T16:12:09
|
|
x11: make msb_pos return unsigned
It was initially returning -1 for all-zero arguments, but now it returns
0.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
769b91c5
|
2014-02-08T15:30:05
|
|
Use (1u << idx) instead of (1 << idx) where appropriate
It doesn't matter (I think), since the implicit conversion doesn't have
any effect (e.g. sign-extension). But it's better to be aware of the
type.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
623b10f8
|
2014-02-08T00:27:54
|
|
Fix sign-compare warnings
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ed18f7dd
|
2014-02-07T17:13:03
|
|
x11: add #actions == #syms check
This must always hold (but if there are no actions, #actions==0), and
explicitly ensures there won't be a division-by-zero a bit below.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
125bb19e
|
2014-02-07T17:11:49
|
|
x11: add explicit cast in mods conversion
Explicit is better and all.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
eb348255
|
2013-07-20T23:21:44
|
|
x11: add XKB protocol keymap and state creation support
These are function to create an xkb_keymap directly from XKB requests
to the X server. This opens up the possibility for X clients to use
xcb + xcb-xkb + xkbcommon as a proper replacement for Xlib + xkbfile for
keyboard support.
The X11 support must be enabled with --enable-x11 for now.
The functions are in xkbcommon/xkbcommon-x11.h. It depends on a recent
libxcb with xkb enabled. The functions are in a new libxkbcommon-x11.so,
with a new pkg-config file, etc. so that the packages may be split, and
libxkbcommon.so itself remains dependency-free.
Why not just use the RMLVO that the server puts in the _XKB_RULES_NAMES
property? This does not account for custom keymaps, on-the-fly keymap
modifications, remote clients, etc., so is not a proper solution in
practice. Also, some servers don't even set it. Now, the client just
needs to recreate the keymap in response to a change in the server's
keymap (as Xlib clients do with XRefreshKeyboardMapping() and friends).
Signed-off-by: Ran Benita <ran234@gmail.com>
|