Sway resets keyboard layout to first after TTY switch

[kchibisov]

To repro, open terminal, try typing into it, change layout, type again, switch to some TTY, switch back, continue typing, you'll see that layout was changed. Also, it seems like this layout change isn't propagated via IPC as well, so it seems like it was done unconditionally.

sway version 1.4-c22caa54 (Jun 13 2020, branch 'HEAD')

config

input * {
  xkb_layout us(dvorak),us
  xkb_options grp:shifts_toggle
}
set $mod Mod4
bindsym $mod+Shift+q kill
set $execnoid exec --no-startup-id
bindsym $mod+Shift+f fullscreen toggle
bindsym $mod+Shift+space floating toggle
bindsym $mod+space focus mode_toggle
bar {
        mode hide
        hidden_state show
        modifier none
        position top
        status_command exec /home/malc/tmp/sway/status
        colors {
               background #393b3f
               statusline #ffffff
        }
}
focus_follows_mouse no
for_window [tiling] floating enable
bindsym $mod+t $execnoid alacritty
bindsym $mod+Shift+t $execnoid stwrap
bindsym $mod+Shift+d $execnoid sway bar hidden_state toggle
output DP-1 scale 2
xwayland disable

log.txt

[eHammarstrom]

I'll just chip in and say that I've stumbled upon this issue. I'll see if I get some time this week to look into it

[RedSoxFan]

libinput is releasing the devices when switching to a different TTY and they are being rediscovered when switching back. When the device is rediscovered, it gets configured using the input config for the device, which does not include the layout index.

I think the best way to resolve this would be to add the index in the input config and set the index when applying the input config. On a change to the layout, store the new index. On a change to keymap, reset the index. input configs are removed and recreated on reload so that should not require any changes. This solution would allow for the layout index to being reapplied whenever the device is lost and rediscovered such as a TTY switch, suspend/resume, manually unplugging and plugging back in.

Also, it seems like this layout change isn't propagated via IPC as well

I think a xkb_keymap event should be getting sent here, but not a xkb_layout event. If so, that includes an implicit layout change since changing the keymap will default to the first layout index.

I'm not seeing any input related ipc events in the log, but I think they only get logged when there is a client subscribed to them.

[eHammarstrom]

Had the same problem with the Debian package of sway (pkg. sway 1.4-2). However, I cannot reproduce this on sway version 1.5-rc1-c8224270 in passthrough mode, I can reproduce it on the Debian "1.4-2" binary in passthrough mode.

Is this something that has been explicitly fixed @RedSoxFan?

[RedSoxFan]

Is this something that has been explicitly fixed @RedSoxFan?

I have a branch (https://github.com/RedSoxFan/sway/tree/ic-store-layout-index) that implements my solution above. Unfortunately, I'm hesitant to open a PR for it since it makes #5455 more noticeable.

I cannot reproduce this on sway version 1.5-rc1-c8224270 in passthrough mode, I can reproduce it on the Debian "1.4-2" binary in passthrough mode.

It's possible that swaywm/wlroots#2048 may have fixed this for the wayland backend, but I haven't tested that.

[eHammarstrom]

It's possible that swaywm/wlroots#2048 may have fixed this for the wayland backend, but I haven't tested that.

FYI, I could not reproduce the bug by dropping that commit.

[RedSoxFan]

FYI, I could not reproduce the bug by dropping that commit.

Ah well, it was just a quick guess. I'd have to take a deeper look at the changes to see what would have fixed it for the wayland backend. Unfortunately, whatever it was won't have an effect on the DRM backend due to the difference in the way input devices are handled.

[emersion]

FYI, I could not reproduce the bug by dropping that commit.

This is expected. Prior to this commit, the Wayland backend would not destroy and re-create the input devices when wl_seat.capabilities changes.

When switching TTYs, this is exactly what happens: libinput devices are removed and re-added when switching back.

[Geo25rey]

Also, num lock turns off on tty switch, using current latest release.

[RedSoxFan]

Also, num lock turns off on tty switch, using current latest release.

Can you please submit a separate issue for that?

[Geo25rey]

Since Sway has callbacks for when input devices are added and removed, a possible solution is to save the xkb_state when a keyboard is removed and restore the xkb_state when the keyboard is added again. It would be nice to only perform these actions when switching to and from other TTYs, but it doesn't seem like Sway can understand whether it in the active TTY. There might be some hope in wlroots's DRM backend, since it does pause the DRM file descriptor when switching to a TTY. To what I can tell that information isn't propogated to Sway, though.

[FreeFull]

Alternatively, it might be desirable to only save the state of the caps lock, scroll lock and num lock toggles, and keyboard layout, rather than the whole kb state.

[JakeEP]

I have this issue as well, though I'm still on Sway 1.5 (as it's the version in APT). I assume this hasn't been fixed yet as this is still open? I'm currently getting around it by binding $mod+Return to open the terminal and then restore the gb keyboard layout (as it becomes us on opening a new terminal).

bindsym $mod+Return exec $term; exec swaymsg input "1:1:AT_Translated_Set_2_keyboard" xkb_layout gb

[mhdna]

Same here.

$ sway -v
sway version 1.8.1