This patch introduces a dedicated layout type for defining layers which are
intended to have a higher degree of permanence.
E.G
[dvorak:layout]
a = a
s = o
#etc...
[control]
1 = setlayout(dvorak)
Impetus:
The semantics afforded by normal layers are a common source of
confusion for users, who often try to toggle letter layouts and end up
inadvertently abusing stacking behaviour.
Additionally, while letter layouts can be defined and toggled like any
other layer, it is sometimes desirable to distinguish between these and
transient layers like nav clusters (#253).
To solve this, a new layer type expressly intended for defining layouts
is introduced; the layout. This also allows for dedicated
actions which operate exclusively on either type (e.g clear()).
Layouts have the following properties:
1. Only one may be active at any given time.
2. They cannot have any associated modifiers.
3. They cannot be used by actions which require a layer as an argument.
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.
- usleep was removed in POSIX.1-2008 (X/Open Issue 7)
- DT_DIR and flock are BSD extensions but BSDs don't use _DEFAULT_SOURCE
- _DEFAULT_SOURCE in GNU exposes POSIX.1-2008 + BSD + SysV mix
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.
Sometimes in Sway, when an application goes from fullscreen to
windowed mode, there is neither a "app_id" or "window_properties"
attribute. Avoid throwing an exception for this case.
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).
Raheman Vaiya
Jakub Jirutka
Ali Shahid
Jan Beich
Sean Estabrooks