Swtich from
<name> = <key>
to
<key> = <name>
and confine keys to a single alias. This is arguably more intuitive
and reduces both config and implementation complexity.
While such a race condition mitigated by the commit theoretically
possible, evidence for it has yet to emerge (it didn't fix#162), and
routing events through the virutal keyboard causes the xinput issue
fixed in 88c84757.
To mitigate potential downstream race conditions when key/mouse events are sent
in quick succession (e.g oneshot clear mouse click), we send all button and key
events through the same virtual device.
All movement is still routed through a dedicated virtual pointer to minimize
display server input issues.
Add support for repeat events to the uinput output. This is achieved
using a dedicated thread in the vkbd output logic.
Similar functionality was introduced in 81c3d53f4c before the rewrite. This
solution is a bit cleaner (albeit more expensive) since it confines the
relevant code to the uinput vkbd and more closely simulates behaviour
of the real drivers (e.g by not generating redundant repeat events).
Tidy up the parsing logic and make everything valid c11
while we are at it :P.
The patch also eliminates the optional macro argument from swap(),
replacing it with a dedicated function (swap2()).
This breaks compatibility with a small number of configs,
but makes things more consistent.
This patch allows macro chains of the form key1+key2
to be punctuated with timeouts. It is mainly useful
to account for broken software which assumes human-scale
timeouts between key down and key up events.
E.G
leftcontrol+n+30ms
will force a 30ms delay between '<leftcontrol down> <n down>'
and the subsequent '<leftcontrol up> <n up>'.
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).
Raheman Vaiya