Sway: Keyboard layout-per-window feature

[Adonai]

Hi, was just wondering if layout-per-window feature possible or planned in swaywm.

Thanks for this great project.

[ddevault]

This is possible in theory, but no one has started working on it.

[manonthemat]

I would love to have that feature.

[ddevault]

So start working on it.

[Hi-Angel]

Could somebody briefly outline what to look at?

Am I correct that "windows" in the code are wrapped into wlr_box?

Where or how "keyboard focused window" is implemented? (as I recently learned, currently focused window is not necessarily the one receiving keyboard input — does that need to be changed btw?)

[Hi-Angel]

Some status update:

So far I figured:

1. A window is represented by sway_view, so I need to keep layout state there
2. An active layout seems to be stored in an opaque struct xkb_state; with bunch of other stuff such as enabled LEDs and pressed keys.
3. It seems, layout change is not handled by sway at all, but rather by libxkbcommon. I.e. I got an impression that sway knows nothing about current keyboard layout.

My current problems:

1. How to get notified of layout change.
2. How to extract the new layout (to store it into sway_view).
3. How to change layout (e.g. when input focus changed from one sway_view to another).

[Hi-Angel]

My work-in-progress branch. TODOs:

1. ✓ SOLVED Where to put the code to stash keyboard layout when keyboard focus changes from one sway_view to another? I'm guessing it's probably the same place where I'm restoring layout (seat_send_focus()), then I need to figure out, how to get the previously focused sway_view.
2. ✓ SOLVED How a configuration option to enable it should look like?
3. The xkb_layout_index_t is probably specific to a xkb_state, hence I need to store it for every keyboard device.

[Hi-Angel]

I kind of stuck with the following question: after I updated xkb_state with new layout, I need to forward the update down the stack to change state of LEDs (if needed) and probably something else (not sure yet what is exactly, but without that the next keypress uses old keyboard layout).

So I did some research with debugger, and came to conclusion that physical keyboard state update is done by wlroots. However I didn't see a function that simply makes update, given a changed xkb_state. Do I need to extract that functional, or am I missing something?

---

Solved by using wlr_keyboard_notify_modifiers() to set keyboard layout.

[eternal-sorrow]

I tried to implement this as a separate IPC script, which will also serve as layout indicator for Waybar, but I was unable to find any way to programmatically switch layout short of executing sway command (IPC analogue of swaymsg input <input name> xkb_layout en), which is definitely not what I want.

[emersion]

I was unable to find any way to programmatically switch layout short of executing sway command

Hmm. swaymsg -t get_inputs gives xkb_active_layout_name, but we provide no way to list available layouts or to set the active one. IMHO those would be good additions.

[eternal-sorrow]

@emersion, also it would be good to have an IPC event when layout is switched.

[emersion]

also it would be good to have an IPC event when layout is switched.

Yes. Patches welcome.