The server used to have to go and do this on our own, but we can do
better than that: after we've compiled the keymap, go through and bind
virtual modifiers to everything that needs it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Right now we just silently ignore overlay controls, which is probably
bad, but it's not the easiest to fix.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
It looks like this could never have worked anyway, what with num_rg
always being 0 everywhere. Remove it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The XkbKey* macros used to work through XkbCM* and XkbSM* variants, for
the xkb_map and xkb_server_map respectively; the latter versions weren't
used by anyone at all, so just bin them and make the macros work
directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
They're no longer needed since we don't expose any atoms in the
published API anymore. As a result, we don't need to support external
atom implementations either. Result!
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ironically, the test for named.xkb included a call that relied on the
default keymap, without the file naming an explicit default. Go figure.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On many layouts, the following error appears:
Internal error: Could not resolve keysym 10005b0
(Which is like the trademark of libxkbcommon now, and makes
unicode-heavy symbol files pretty useless).
This occurs when a keysym string (in this case, 10005b0) is passed to
xkb_string_to_keysym, but cannot be resolved.
This in turn happens because the parser passes on hexadecimal keysym
strings without the leading "0x", thus leaving the resolving function
without a way to disambiguate it as a number.
Therefore, make sure to pass on the "0x". The file symbols.c in xkbcomp
project does the same; it probably got lost in translation.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
This rules file won't be loaded more than once in most cases anyway, so
just load it again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
Instead, just parse the same file again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone
Ran Benita