Repository navigation
Windows Terminal 1.1 breaks remapped CapsLock key inside WSL #7120
Description
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
Activity
DHowett commentedon Jul 29, 2020
So, I actually can reproduce this in WSL outside of the Terminal.
Here's the result of pressing my remapped caps lock under
showkey -ato 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:
\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
remapped
second field is
29in real and0in the remapchristianfosli commentedon Jul 30, 2020
Thanks, Dustin L. Howett (@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 commentedon Jul 30, 2020
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 commentedon Aug 6, 2020
So, somebody else reported a similar bug and Leonard Hecker (@lhecker) investigated it pretty quickly. We think we can fix this on our side 😄 without requiring any powertoys changes.
Fix #7064: Ignore key events without scan code (#7145)
Fix #7064: Ignore key events without scan code (#7145)