This patch attempts to minimize the number of extraneous modifier events. We
used to do this in v1, but impetuously abandoned the attempt in the name of
reducing code complexity.
We achieve this by strategically updating modifier state and internally
reintroducing key sequences as distinct (from macros) entities, which are tied
to the generating key down/up pair.
This will be transparent to most users, but should make the output sequences
easier to reason about and may help in certain edge cases (#184) or in the
case of software with buggy input systems (#181).
This patch makes simple macros of the form `<mods>-<key>` less noisy by
avoiding the redundant release/depression of modifiers which are already
active. This used to be the default behaviour prior to 2.3.0-rc, but was
changed to accommodate #128 (among other things). In most cases the
additional noise is transparent to the application, but notably breaks
Gnome tab-switching via swap, since Gnome cares about intermediate
modifier state.
A potential race condition exists on systems where keyd-application-mapper
is started before keyd (ideally this shouldn't happen, but exotic
setups exist). To allow initialization order to be reversed, we simply
eliminate the ping check on script initialization.
Removing this is mostly harmless since keyd -e will silently
fail until the daemon is started anyway, and any errors will show up
in the log file.
Currently composite layers will be activated in the order in which they
are defined which can cause shorter sequences to take precedence over
longer ones. This patch ensures the longest composite sequence always
takes precedence.
The stock XCompose file which ships with most distros isn't exhaustive
and uses a number of layout specific keysyms intended to be easy to
memorize (rather than globally accessible). To circumvent this problem
we ship our own set of simplified compose definitions.
This patch passively monitors mouse events and passes them
through to the active keyboard in order to facilitate
clearing oneshot modifiers on click.
A byproduct of this is an increase the number of spurious wakeups
(caused by mouse movement since we can't exclusively monitor click
events) , but this seems to have an minimal performance impact
in practice.
It seems the uinput API changed at some point. This patch
uses the legacy API for virtual device creation in order
to support kernels older than 4.4.
Refs:
052876f8e5
If we encounter a utf8 sequence corresponding to a glyph for which a
known XKB compose sequence exists, we replace the glyph with the
corresponding sequence. This allows non-english users to easilly specify
alternate glyphs without having to memorize the appropriate macros.
This is a major release which breaks backward compatibility for
non-trivial configs. (we are still in beta after all :P).
In the absence of too much blowback this will probably become the final
v2 design.
Much of this harkens back to the v1, with some additional simplifications
and enhancements.
See DESIGN.md for a more detailed account.
Use EVIOCGKEY to obtain keystate of the underlying device instead of
exclusively relying on internal state + timeouts. The old approach was
racey and slow. This should improve start up/reload times and make
initialization less buggy.
- remove unnecessary cruft from struct config
- efficiently scan the config directory for matching
files on device detection.
- make keyboard->config the single source of truth
This should also speed up config reloading and reduce memory usage.
Constrain key codes to the range < 256 so they fit inside a single byte.
In theory individual evdev codes may exceed this but in practice most
keys seem to fit in this range, and it generally seems to be more
portable (e.g USB HID spec).
The mod mask has also been demoted to uint8_t since 16 bits was an
unreasonable size to begin with.
This should significantly reduce the memory footprint.
Some applications make use of the alt (e.g firefox) and meta (e.g gnome)
keys in isolation. Thus it is necessary to interpose additional events
to prevent the likes of '<alt down> <alt up>' from being interpreted as
key presses.
E.G
[alt]
a = x
will currently cause 'alt+a' to produce:
<alt down>
<alt up>
<x down>
<x up>
In most cases this is identical to '<x>', however in some contexts the
additional alt keypress is meaningful.
To prevent this, we intelligently emit '<alt>+<control>' instead by sandwiching the
'<alt up>' event like so: '<control down> <alt up> <control up>'
The full sequence thus becomes:
<alt down>
<control down>
<alt up>
<control up>
<x down>
<x up>
Raheman Vaiya
Luke Dennis
mamg22