Sway: Character is printed when reload configuration

[Axenntio]

I have this in my configuration

# Reload the configuration file
    bindsym $mod+Shift+r reload

When I press the shortcut, sway reload the configuration, then put a R in my current window.
I'm on sway version 1.4

[cryptoluks]

Same issue for me. Same version.

[ohk2kt3t4]

Does it happen with other letters too?

[RedSoxFan]

Related https://github.com/swaywm/wlroots/pull/1973
I haven't gotten around to looking into a better solution

[cryptoluks]

Does it happen with other letters too?

Yes, I reload my config with $mod+Shift+c and a capital "C" is printed when reloading.

[declanqian]

Yeah. It happens to me too.

[damneq]

Same thing here, using $mod+Shift+c and capital "C" is printed

[the-antz]

Same here, for me it prints a 'C' with the default bind, version is 1.4.

[zwma]

sway version 1.4, I reload through a menu by pressing the return key and 2 returns are printed. By the way, I've noticed that it only happens if I have an input type:keyboard block in the config file.

[l4tte]

I can't replicate, it's probably a config issue like @dwma suggested

[cryptoluks]

Yes, I can confirm the issue is solved when removing the keyboard block. But that's obviously not an option. :smile:

input type:keyboard {
    xkb_layout de
    xkb_variant nodeadkeys
    xkb_options caps:hyper
}

[craigbarnes]

I get the same bug in 1.4, when my config contains:

input type:keyboard {
    xkb_options caps:ctrl_modifier,compose:ralt
    repeat_delay 350
    repeat_rate 25
}

bindsym $mod+r reload

It seems like it might be because cmd_reload() resets inputs and at some point $mod+r is re-interpreted as being pressed, but not yet bound to anything.

The behaviour when running swaymsg reload from a terminal also seems wierd. It seems to insert extra newlines, even if you just tap Enter.

[schauveau]

I found a simple workaround. The idea is to bind the reload command on a key release and to also bind a fake action (nop) on the key press.

bindsym $mod+Shift+c nop                                                                            
bindsym --release $mod+Shift+c reload

[xPMo]

Just want to add that this is not exclusive to reload.

Typing Return to execute swaymsg command, then $mod+2 to return to the previous workspace

My keyboard config:

input type:keyboard xkb_file $HOME/.xkb/custom.xkb

[vvrein]

Hi all!
Idk whether for this should be different issue opened, but swaymsg *** also prints newline characters on exec:
https://tort.icu/bin/raw/k55mtgkq.mp4

This behavior could be omitted with adding sleep 0.04 before swaymsg.
So, for example, this swaymsg focus left prints characters after exit.
And this - not: sleep 0.04 && swaymsg focus left

Btw, there is correlation, between
how much time window with swaymsg command issued was unfocused,
and
how much time newlines printed, when focus returned to the window.

[RedSoxFan]

@vvrein
That's an entirely different issue. I thought we already sent key release events on focus change. You can submit a separate issue for investigation. Please include the log of env WAYLAND_DEBUG=1 <terminal> for the terminal. Wayland Debug logs get very verbose so please try to keep it as close to the beginning and end of the reproduction steps as possible.

--

As for this issue, a little bit of an explanation for what's going on. First off, this will happen when a keyboard is added to or removed from a wlr_keyboard_group while they have a key pressed that is not currently being pressed by any other keyboard in the group (key events for a wlr_keyboard_group are treated as a set). In this case, it is the keys for the reload binding. However, it could also occur if you are changing the keymap or key repeat settings for a keyboard as that will also trigger it to change groups.

The reasoning for this is the wlr_keyboard_group is sending a key event to the compositor to allow it to update its internal state. The issue is these are not normal key events, they are just a state change. They are not the result of an actual key press or release. However, they are necessary to avoid state corruption. Additionally, the release also needs to be sent to the focused surface if a press event was sent to the surface to avoid keyboard state corruption for the surface.

The solution that I'm leaning towards is to switch these over to use a new wlr_keyboard_group event. This would allow for the compositor to handle these differently then normal key events. The workflow for these events would be as follows:

• Update compositor state
• Do NOT trigger bindings
• If a key release and the corresponding key press was sent to surface, send key release to surface (to prevent the surface's state from being corrupt). For key press or a release without a press sent to the surface, do NOT send to surface.

[emersion]

Yes, I think we need something similar to wl_keyboard.enter for wlr_keyboard.

[vvrein]

Idk would it be helpful, here is one more way to get such a glitch

_sway version 1.4-f7f7179f (May 25 2020, branch 'master')_
_zsh_

UPD:
this happens only with keyboard config lines in sway conf file.
Here is myne:

input type:keyboard {
    repeat_rate 40
    repeat_delay 250
    xkb_file ~/.config/xkb/vrein-custom
}

[vvrein]

@craigbarnes https://github.com/swaywm/sway/issues/4975#issuecomment-599755905

The behaviour when running swaymsg reload from a terminal also seems wierd. It seems to insert extra newlines, even if you just tap Enter.

@xPMo https://github.com/swaywm/sway/issues/4975#issuecomment-612960093
yours bugs is likeky related to #5379

There is two different bugs, with similar at first glance behavior.

First one (this) #4975 - is about re-adding kb to kb group at sway reload.
Second one #5379 - is about printing characters.

[fleaz]

Hey, same issue over here. The problem appears not when you add an input {} block, but when this block contains a xkb_layout entry. When using my keyboard in the default layout from sway (english) the bug is gone, but as soon as I switch to de the issue appears.

[RedSoxFan]

@fleaz #5393 should fix this issue