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
mamg22
Jan Beich