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>
Reverse the consolidation of keyd events into a single virtual
device since this still causes problems with xinput. Instead
we now lazily initialize the pointer on an as-needed basis
to minimize interference with things which behave differently
in the presence of an external pointer (e.g libinput touchpad
disabling).
The end result should (hopefully) be a little more robust (and systemd independent).
I no longer remember what possessed me to switch away from the original
inotify implementation, but udev detection seems to have caused
enough grief to warrant switching back.
This will probably break FreeBSD support without some kind of
inotify glue and/or a kqueue implementation. If any FreeBSD
users see this feel free to open an issue or submit a PR :P.
Raheman Vaiya
Luke Dennis
mamg22
Jan Beich