|
05d13d5f
|
2025-06-26T16:58:50
|
|
include: Fix infinite loop
Fixed including an absolute path with no default map triggering an
infinite loop.
|
|
|
ee87f6ed
|
2025-06-21T19:28:53
|
|
state: Fix broken latch not honoring clearLocks=no
Before this commit, breaking a latch (modifier & group) would always
clear locks, even if `clearLocks=no`.
|
|
|
69c3d257
|
2025-06-17T16:43:05
|
|
keymap: Add parameter `latchOnPress` for LatchMods()
Some keyboard layouts use `ISO_Level3_Latch` or `ISO_Level5_Latch` to
define “built-in” dead keys:
- they do not rely on the installation of custom Compose file;
- they do not clash with other layouts.
However, layout projects usually want the exact same behavior on all OS,
but the XKB latch behavior (often misunderstood) also acts as a *set*
modifier, which is not expected.
The usual behavior of a dead key on Linux, macOS and Windows is:
- latch on press;
- deactivate as soon as another (non-modifier) key is pressed.
Added the parameter `latchOnPress` to `LatchMods()` to enable the
aforementioned behavior.
As it is incompatible with X11, this feature is available only using the
keymap text format v2.
[XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
|
|
|
551cca2a
|
2024-12-03T10:12:03
|
|
state: Add server API for updating latched and locked mods & layout
Up to now, the “server state” `xkb_state` API only offered one entry
point to update the server state – `xkb_state_update_key`, which reflects
the direct keyboard keys state. But some updates come out-of-band from
keyboard input events stream, for example, a GUI layout switcher.
The X11 XKB protocol has a request which allows for such updates,
`XkbLatchLockState`[^1], but xkbcommon does not have similar
functionality. So server applications ended up using
`xkb_state_update_state` for this, but that’s a function intended for
client applications, not servers.
Add support for updating the latched & locked state of the mods and
layout. Note that the depressed states cannot be updated in this way --
XKB does not expect them to be updated out of band.
[^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State
Fixes: #310
Signed-off-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
1c352199
|
2020-09-07T11:35:22
|
|
test/data: sync from xkeyboard-config 2.30
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
c6ee6371
|
2014-10-16T17:48:00
|
|
test/data: sync to xkeyboard-config 2.13
(Run ./test/data/sync.sh).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
0c8e9e0c
|
2013-07-22T18:43:53
|
|
test: sync test/data from xkeyboard-config 2.9
Needed for some tests. The tests need some adjustment, mostly because of
the resolution of xkeyboard-config bug
https://bugs.freedesktop.org/show_bug.cgi?id=50935
Also add the 'ch' symbols file for future tests.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
40581106
|
2013-02-17T11:22:41
|
|
Sync test data from xkeyboard-config
Sync the files again from xkeyboard-config 2.8, since there have been
some changes we should test against.
Also added a script test/data/sync.sh if we want to do it again in the
future.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
62deaeb5
|
2012-07-12T14:42:31
|
|
Import dataset into test/data/
Use a self-contained dataset instead of relying on a globally-installed
set. Data taken from xkeyboard-config 2.5.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|