| Age | Commit message (Collapse) | Author |
|---|
|
If a sway keyboard is being destroyed, then the keyboard is being
removed from a seat. If the associated wlr_keyboard is the currently
set keyboard for the wlr_seat, then we need to reset the wlr_seat's
keyboard to NULL so it doesn't reference an invalid device for the seat.
The next configured keyboard from the seat or the next keyboard from
that seat that has an event will then become the seat keyboard.
Similarly, this needs to be done for a wlr_keyboard_group's keyboard
when the wlr_keyboard_group is being destroyed.
|
|
In sway_keyboard_destroy, only remove the keyboard from a keyboard
group, if it is part of a keyboard group. If the keyboard is not part of
a keyboard group, then there is nothing to remove it from
|
|
A wlr_keyboard_group allows for multiple keyboard devices to be
combined into one logical keyboard. This is useful for keyboards that
are split into multiple input devices despite appearing as one physical
keyboard in the user's mind.
This adds support for wlr_keyboard_groups to sway. There are two
keyboard groupings currently supported, which can be set on a per-seat
basis. The first keyboard grouping is none, which disables all grouping
and provides no functional change. The second is keymap, which groups
the keyboard devices in the seat by their keymap. With this grouping,
the effective layout and repeat info is also synced across keyboard
devices in the seat. Device specific bindings will still be executed as
normal, but everything else related to key and modifier events will be
handled by the keyboard group's keyboard.
|
|
This fixes an inverted fclose return value check and simplifies the
error handling and logging for xkb_file in sway_keyboard_compile_keymap
|
|
This keeps track of whether surfaces received a key press event and
will only send a key release event if the pressed event was sent. This
also requires changing the keycodes that are sent via wl_keyboard_enter
to only include those that were previously sent. This makes it so
surfaces do not receive key release events for keys that they never
received a key press for and makes it so switching focus doesn't leak
keycodes that were consumed by bindings.
|
|
This adds support for specifying a binding for a specific group. Any
binding without a group listed will be available in all groups. The
priority for matching bindings is as follows: input device, group, and
locked state.
For full compatibility with i3, this also adds Mode_switch as an alias
for Group2. Since i3 only supports this for backwards compatibility
with older versions of i3, it is implemented here, but not documented.
|
|
In sway_keyboard_config, do not change the keymap when the new keymap
is unchanged, unless this is during a config reload. The reasoning for
this is to prevent the effective layout from being reset to index 0 for
input config changes unrelated to the keymap.
|
|
This adds an ipc event related to input devices. Currently the
following changes are supported:
- added: when an input device becomes available
- removed: when an input device is no longer available
- xkb_keymap_changed: (keyboards only) the keymap changed
- xkb_layout_changed: (keyboards only) the effective layout changed
|
|
Adds a new commend "xkb_file", which constructs the internal
xkb_keymap from a xkb file rather than an RMLVO configuration.
This allows greater flexibility when specifying xkb configurations.
An xkb file can be dumped with the xkbcomp program.
|
|
Before the delta input config is stored, this attempts to compile a
keymap with it. If the keymap fails to compile, then the first line of
the xkbcommon log entry will be included with a `CMD_FAILURE`, the
entire xkbcommon log entry will be included in the sway error log, and
the delta will not be stored.
This only handles basic issues such as a layouts not existing. This
will NOT catch more complex issues such as when a variant does
exist, but not for the given layout (ex: `azerty` is a valid variant,
but the `us` layout does not have a `azerty` variant).
|
|
This changes the behavior of bindings to make the `BINDING_LOCKED` flag
conflicting, which will allow for both unlocked and locked bindings.
If there are two matching bindings and one has `--locked` and the other
does not, the one with `--locked` will be preferred when locked and
the one without will be preferred when unlocked.
If there are two matching bindings and one has both a matching
`--input-device=<input>` and `--locked` and the other has neither, the
former will be preferred for both unlocked and locked.
This also refactors `get_active_binding` in `sway/input/keyboard.c`
to make it easier to read.
|
|
This attempts to use the default keymap when the one defined in the
input config fails to compile. The goal is to make it so the keyboard
is always in a usable state, even if it is not the user's requested
settings as usability is more important.
This also removes the calls to `getenv` for the `XKB_DEFAULT_*` family
of environment variables. The reasoning is libxkbcommon will fallback
to using those (and then the system defaults) when any of the rule
names are `NULL` or an empty string anyway so there is no need for
sway to duplicate the efforts.
|
|
|
|
|
|
This fixes the criteria for emitting a `bar_state_update` event to
notify swaybar (and any other bars utilizing the event) on whether the
bar is visible by modifier. It is not enough to only emit the event
when both the bar mode and bar hidden state are `hide` since it is
possible to release the modifier while hidden state is `show` and then
change hidden state to `hide` without pressing the modifier. This also
emits the event whenever visible by modifier is set and should no
longer be regardless of the mode and state to ensure that it gets
properly cleared. If visible by modifier is not set and the bar is not
in `hide`/`hide`, then no events will be sent and visible by modifier
will not be set
|
|
Allows both BackSpace and Shift+BackSpace to be bound under the US
keyboard layout, per #3705.
|
|
If `repeat_rate` or `repeat_delay` is set without the other being set,
the default was being used for both. This changes the logic to respect
the value given and use the default for the other when only one is set.
|
|
sway-bar(5) documents `modifier none`, which comes from i3. This
implements the functionality for `modifier none` since it was not
previously implemented. The bar modifier toggles visibility of the bar
when the bar mode is set to hide. When the bar modifier is set to
`none`, the ability to toggle visibility of the bar will be disabled.
|
|
Modifier handling functions were moved into sway/input/keyboard.c;
opposite_direction for enum wlr_direction into sway/tree/output.c;
and get_parent_pid into sway/tree/root.c .
|
|
This commit mostly duplicates the wlr_log functions, although
with a sway_* prefix. (This is very similar to PR #2009.)
However, the logging function no longer needs to be replaceable,
so sway_log_init's second argument is used to set the exit
callback for sway_abort.
wlr_log_init is still invoked in sway/main.c
This commit makes it easier to remove the wlroots dependency for
the helper programs swaymsg, swaybg, swaybar, and swaynag.
|
|
When resetting the keyboard during reload, disarm the key repeat on all
keyboards since the bindings (and possibly keyboard) will be freed before
the key repeat can go off.
|
|
Since the keyboard can be destroyed by executing a binding (reloading
with a different seat attachment config), update the repeat timer before
executing the binding.
|
|
This makes bindings more snappy when the user is typing faster than
his keycaps are releasing.
Signed-off-by: Franklin "Snaipe" Mathieu <me@snai.pe>
|
|
The input manager is a singleton object. Passing the sway_input_manager
argument to each of its functions is unnecessary, while removing the
argument makes it obvious to the caller that it's a singleton. This
patch removes the argument and makes the input manager use server.input
instead.
On a similar note:
* sway_input_manager.server is removed in favour of using the server
global.
* seat.input is removed because it can get it from server.input.
Due to a circular dependency, creating seat0 is now done directly in
server_init rather than in input_manager_create. This is because
creating seats must be done after server.input is set.
Lastly, it now stores the default seat name using a constant and removes
a second reference to seat0 (in input_manager_get_default_seat).
|
|
bindsym --input-device=<identifier> ...
bindcode --input-device=<identifier> ...
|
|
Since wayland does not currently allow swaybar to create global
keybinds, this is handled within sway and sent to the bar using a custom
event, so as not to pollute existing events, called bar_state_update.
|
|
|
|
This patch makes it so when you run reload, the actual reloading is
deferred to the next time the event loop becomes idle. This avoids
several use-after-frees and removes the workarounds we have to avoid
them.
When you run reload, we validate the config before creating the idle
event. This is so the reload command will still return an error if there
are validation errors. To allow this, load_main_config has been adjusted
so it doesn't apply the config if validating is true rather than
applying it unconditionally.
This also fixes a memory leak in the reload command where if the config
failed to load, the bar_ids list would not be freed.
|
|
|
|
seat_execute_command needs to check the flags on `binding_copy`, as
`binding` will be a dangling pointer after a reload command.
handle_keyboard_key needs to set the next_repeat_binding for
non-reloads prior to executing the command in case the binding is
freed by the reload command.
|
|
Fixes #2568
The binding that gets stored in the keyboard's `repeat_binding` would
get freed on reload, leaving a dangling pointer.
Rather than attempt to unset the keyboard's `repeat_binding` along with
the other bindings, I opted to just not set it for the reload command
because there's no point in reloading repeatedly by holding the binding.
This disables repeat bindings for the reload command.
As we now need to detect whether it's a reload command in two places,
I've added a binding flag to track whether it's a reload or not.
|
|
Now 'repeat_delay' and 'repeat_rate' control the initial delay
and rate (per second) of repeated binding invocations.
If the repeat delay is zero, binding repetition is disabled.
When the repeat rate is zero, the binding is repeated exactly
once, assuming no other key events intervene.
|
|
Each sway_keyboard is provided with a wayland timer event source.
When a valid keypress binding has been found, a callback to
handle_keyboard_repeat is set. Any key event will either clear
the callback or (if the new key event is a valid keypress binding)
delay the callback again.
|
|
keyboards would have 'numlock mode' enabled, remapping parts of the alphabet to numbers.
|
|
|
|
After setting the keymap, try to enable NumLock and disable CapsLock.
This only works if sway has the xkb master state and controls the keyboard.
Prepare configuration settings for later use as well.
|
|
The mouse binding logic is inspired/copied from the
keyboard binding logic; we store a sorted list of the
currently pressed buttons, and trigger a binding when
the currently pressed (or just recently pressed, in
the case of a release binding) buttons, as well as
modifiers/container region, match those of a given
binding.
As the code to execute a binding is not very keyboard
specific, keyboard_execute_command is renamed to
seat_execute_command and moved to where the other
binding handling functions are. The call to
transaction_commit_dirty has been lifted out.
|
|
First, the existing sway_binding structure is given an
enumerated type code. As all flags to bindsym/bindcode
are boolean, a single uint32 is used to hold all flags.
The _BORDER, _CONTENTS, _TITLEBAR flags, when active,
indicate in which part of a container the binding can
trigger; to localize complexity, they do not overlap
with the command line arguments, which center around
_TITLEBAR being set by default.
The keyboard handling code is adjusted for this change,
as is binding_key_compare; note that BINDING_LOCKED
is *not* part of the key portion of the binding.
Next, list of mouse bindings is introduced and cleaned up.
Finally, the binding command parsing code is extended
to handle the case where bindsym is used to describe
a mouse binding rather than a keysym binding; the
difference between the two may be detected as late as
when the first key/button is parsed, or as early as
the first flag. As bindings can have multiple
keycodes/keysyms/buttons, mixed keysym/button sequences
are prohibited.
|
|
Rather than maintain copies of the entire focus stack, this PR
transactionises the focus by introducing two new properties to the
container state and using those when rendering.
* `bool focused` means this container has actual focus. Only one
container should have this equalling true in its current state.
* `struct sway_container *focus_inactive_child` points to the immediate
child that was most recently focused (eg. for tabbed and stacked
containers).
|
|
|
|
|
|
fixes #2169
|
|
* Ensure that modifier keys are identified even when the next key does
not produce a keysym. This requires that modifier change tracking
be done for each sway_shortcut_state.
* Permit regular and --release shortcuts on the same key combination.
Distinct bindings are identified for press and release cases; note
that the release binding needs to be identified for both key press
and key release events.
* Maintain ascending sort order for the shortcut state list, and keep
track of the number of pressed key ids, for simpler (and hence
faster) searching of the list of key bindings.
* Move binding duplicate detection into get_active_binding to avoid
duplicating error messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The same shortcut algorithm is now used for keycodes,
raw keysyms, and translated keysyms. Pressed keysyms
are now stored in association with the keycodes that
generated them. Modifier keycodes (and associated
keysyms) are identified retroactively by the subsequent
change to the modifier flags.
|
