Layout block doesn't show the current active layout properly when running under Sway

[asahaf]

I'm using Sway and I have two keyboard layouts which I switch between. The keyboard layout block always shows first (EN) layout even when the current active layout is switched to the secondary layout.

[2m]

I am also seeing wrong output in the keyboard_layout block, but it is different. I have multiple layouts configured in sway:

input "..." {
  xkb_layout us,lt
}

And keyboard_layout block always shows us,lt value and it does not change when I switch layouts.

[atheriel]

Can you provide the output of setxkbmap -query under these conditions?

[asahaf]

This is the output of setxkbmap -query

Cannot open display "default display"

[asahaf]

I've found a workaround using custom block which its command executes this script, where "English (US)" is your primary layout

#!/usr/bin/env bash

x="`swaymsg -t get_inputs | jq --raw-output '[.[] | select(.type == "keyboard") | .xkb_active_layout_name | select(contains("English (US)") | not)] | first'`"
if [[ "${x}" == "null" ]]; then
    echo English
else
    echo "${x}"
fi

Credit: This solution is posted by @jeremejevs at Alexays/Waybar#85 (comment)

[2m]

Can you provide the output of setxkbmap -query under these conditions?

The output is

─╼ setxkbmap -query                                                             0
rules:      evdev
model:      pc105
layout:     us

and the output is the same independent of which layout is currently active.

swaylock detects it correctly, by the way.

[atheriel]

Sway seems to respond to setxkbmap, so I assumed that it would update the state reported by -query. This does not appear to be the case, and if anyone can track down why that would be appreciated.

If this is not a bug, we may need to add a new driver for Sway. I'm not sure if there is a standard way to retrieve the current layout on that platform, but we could use it without much difficulty if it exists. Parsing the output of swaymsg -t get_inputs does not seem very future-proof.

[2m]

And keyboard_layout block always shows us,lt value and it does not change when I switch layouts.

I noticed that I had old X11 configuration in /etc/X11/xorg.conf.d/00-keyboard.conf with Option "XkbLayout" "us,lt". After removing that, keyboard layout now stays empty. I have block configured to use localebus driver.

And busctl confirms that X11Layout is not changed in sway when layout changes:

 ─╼ busctl get-property org.freedesktop.locale1 /org/freedesktop/locale1 org.freedesktop.locale1 X11Layout
s ""

[2m]

Another datapoint: swaylock recognizes the correct keyboard layout when in the lock screen. It uses xkbcommon for that.

[atheriel]

There appears to be an xkbcommon crate, but it's not clear how to retrieve the current layout or listen for changes from the docs. If anyone is willing to take this on I'd happily accept a PR.

[vvrein]

While digging this issue, I found a post describing this issue best.
https://who-t.blogspot.com/2016/12/the-future-of-xinput-xmodmap-setxkbmap.html
There is no one entry point for wm that uses Wayland protocol to get kblayout or something else related.
For sway it would be swaymsg -t get_inputs for other wm - other approach.

[vvrein]

By the way, swaylock seems understand current keyboard layout only after you start typing in it, not when it actually changes.

[asahaf]

sway 1.2 provides a way to subscribe to input change event

swaymsg -t subscribe '["input"]' --monitor

now when you change the layout, you get notified

To get the active layout:

swaymsg -t subscribe '["input"]' --monitor | jq --raw-output 'select(.change == "xkb_layout") .input .xkb_active_layout_name'

[atheriel]

It may be possible to use the i3ipc crate for this as well.

[ammgws]

Unfortunately it doesn't support sway's get_inputs or input events and the maintainer has been AWOL for over 6 months.

[vvrein]

And what about https://github.com/leshow/tokio-i3ipc ?
(just few-seconds-search, idk does it really could help)

UPD: meh, it similarly doesn't have required get_inputs

[ammgws]

There's a sway one but might not be backwards compatible with i3. On mobile atm

[ammgws]

https://github.com/JayceFayne/swayipc-rs/blob/master/src/socket.rs

If only this was updated to check for I3SOCK as well, then I think it could be used for i3 as well since sway is meant to be backwards compatible wrt the JSON protocol.

[vvrein]

Found the same... seems ok for sway

[ammgws]

I guess we could just call swaymsg ourselves

[ammgws]

@vvrein I wanted to see if we could replace i3ipc-rs that we use for the focused_window block with swayipc-rs, so I monkey patched swayipc-rs to read I3SOCK and swayipc-rs seemed to work fine on i3. So we can make this happen like this:

1. Rewrite focused_window block to use swayipc-rs and test it (Done, tested a little in i3 too)
2. Send PR to swayipc-rs to allow using I3SOCK when SWAYSOCK isn't available/manually Done
3. If maintainer accepts the PR then add a new sway driver to the layout block

Related: Switching to swayipc-rs will probably make #532 happen too since i3ipc-rs doesn't look like it will be updated anytime soon

[ammgws]

@asahaf @2m @vvrein
Implemented via #670