Windows Terminal 1.1 breaks remapped CapsLock key inside WSL

[christianfosli]

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.959] (1909)
Windows Terminal version (if applicable): 1.1.2021.0

Any other software? PowerToys v0.19.2, Ubuntu 20.04 WSL fresh install from Microsoft Store with no custom config

Steps to reproduce

• In Windows PowerToys, map "Caps Lock" key to "Ctrl" (left or right doesn't matter)
• Open Ubuntu WSL in Windows Terminal
• Open Vim or Neovim, go into Insert mode
• Press "Caps Lock" (which is mapped to "Ctrl")

Expected behavior

"Caps Lock" should be treated as "Ctrl". No visible result.

Actual behavior

"Caps Lock" is treated as "Control-Space", and tries insert any previously inserted text again.

---

Work-Around

The issue goes away by adding this to settings.json

"experimental.input.forceVT": true,

Therefore it is likely caused by #6309

More Details, Debugging info

I originally thought it was a bug in PowerToys, but since the work-around works, I figure the bug must be here.
It's a bit annoying, because I like to escape out of normal mode in vim by pressing <CapsLock>-[ (which should be treated as <Ctrl>-[, which is again treated as <esc>). Now I instead insert the text i wrote twice.

If i input <Ctrl-V><Caps-Lock> in Vim insert mode, vim inserts <C-Space>. This is how I determined the remapped key is interpreted as <C-Space>.

• This happens only inside Windows-Subsystem for Linux (WSL1) inside windows terminal
• I tested with a new installation of Ubuntu from the Microsoft Store, with no customizations to Ubuntu, Vim or wslconf
• I tested inside and outside of tmux, which did not make any difference
• The issue is not present running WSL from CMD or Powershell, i.e. not using windows terminal.
• The issue is not present running Neovim directly from Powershell Core inside windows terminal
• The issue is not present running vim in Linux (tested Alpine) inside windows terminal as a Docker container

[DHowett]

So, I actually can reproduce this in WSL outside of the Terminal.

Here's the result of pressing my remapped caps lock under showkey -a to dump what the tty driver is generating:

This is an unfortunate casualty of the better (I know, it's ironic) keyboard support offered by #6309. There's two issues here:

1. PowerToys' remapped key doesn't generate a "scancode" like the normal control key does
2. WSL treats any key it receives with no character (Ctrl generates no character) plus no scancode as valid input for \0 (which roughly de-maps to Ctrl+Space, but is also the encoding for Ctrl+Shift+2)

This worked before #6309 because the remote app (here, WSL) was never made aware that somebody pressed Ctrl without a scancode.

WSL can't remove the check in (2) because it would break one of the few valid ways to insert \0. It's best fixed in PowerToys, as it's generating the key event. Once the event comes into Terminal we have no way of determining whether the user actually pressed a scancode-less key and truly wanted a null byte or whether they pressed this somewhat broken remapped Ctrl. ☹️

debugging information

real ctrl (left) key

␛[17;29;0;1;8;1_

remapped

␛[17;0;0;1;8;1_

second field is 29 in real and 0 in the remap

[christianfosli]

Thanks, @DHowett, for finding the root cause and describing in an easy to understand way!
In this case I will close this and create an issue in PowerToys instead.

[christianfosli]

debugging information
real ctrl (left) key

␛[17;29;0;1;8;1_

remapped

␛[17;0;0;1;8;1_

second field is 29 in real and 0 in the remap

How do you find these?
If I open a new bug in PowerToys titled "Capslock -> Control map is missing "scancode".", I should probably include how to debug it properly.

[DHowett]

So, somebody else reported a similar bug and @lhecker investigated it pretty quickly. We think we can fix this on our side 😄 without requiring any powertoys changes.