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).
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.
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.
Raheman Vaiya