Sway keymap resets to default when running external commands from emacs

[tannart]

• Sway Version: sway version 1.2 (Aug 29 2019, Arch Linux)

• Debug Log: https://gist.github.com/MacFarlaneBro/663675d4b614c7716075fce0f704f222

• Configuration File: default config

The issue occurs whenever I launch an external shell command from emacs
gui, the logs in the example given are for the following

• start sway
• open an emacs session using dmenu
• type the shift+2 character on my keyboard which produces the " character as my xkb_layout is set to 'gb'
• execute ls via an external shell command
• typing the shift+2 character now produces the @ character
• exit sway

The keymap can be reverted to the correct setting by reloading my sway config, however all subsequent external shell commands will always shift it back to the default us keyboard layout.

I have provided the full debug log above though as far as I am able to tell from some additional tinkering the key lines indicating the change are as follows:

The XKEYBOARD keymap compiler (xkbcomp) reports:

Warning: Unsupported maximum keycode 569, clipping.
X11 cannot support keycodes above 255.
Warning: Unsupported high keycode 372 for name ignored
X11 cannot support keycodes above 255.
This warning only shows for the first high keycode.
Internal error: Could not resolve keysym XF86MonBrightnessCycle
Internal error: Could not resolve keysym XF86RotationLockToggle
Errors from xkbcomp are not fatal to the X server

[bhearsum]

Not sure if it's the same or not, but I have a similar issue in #4664 that is triggered by starting my terminal emulator.

See /usr/share/X11/xkb/symbols/us for a potential workaround, assuming this is rooted in the same issue as mine.

[tannart]

Just tried out a much lazier variant of your solution (literally just backing up the us file and making a copy of the gb file called us) and that seemed to work great!