Keyboard layout fails to switch second time in fresh WSL2 console

[BarsMonster]

WslLogs-2025-03-02_03-47-33.zip

Windows Version

Microsoft Windows [Version 10.0.22631.4751]

WSL Version

WSL version: 2.4.11.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.1.21.2

Distro Version

22.04

Other Software

No response

Repro Steps

• Have windows with at least 2 keyboard layouts. In my case - English US and Russian.
• Have language bar = hidden (this is a must)
• Open fresh WSL2 console (bash). Do not switch window focus, console window must be on foreground until the end of test.
• write few text characters to see current language
• press win+space to switch keyboard layout first time
• write few text characters and observe correct layout switch
• press win+space to switch keyboard layout second time

Expected Behavior

• Win+Space always switches keyboard layout correctly both on first, second and all further key presses, just like in all other applications.

Actual Behavior

When you write few text characters - you can see that second keyboard layout switch did not worked.

You can see that all further Win+Space key-presses are ignored. But after you switch window focus at least once - it fixes itself, and all future Win+Space presses work correctly.

This behavior was quite unexpected, so I reproduced it on 2 different computers with WSL2. But floating language bar must be hidden. If language bar is hidden, and you HOLD Win+Space - language bar will open anyways in 1-2 seconds, and this also fixes language switching in WSL2 console.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

[github-actions]

Diagnostic information

Issue was edited and new log file was found: https://github.com/user-attachments/files/19041501/WslLogs-2025-03-02_03-47-33.zip
.wslconfig found
	Custom kernel found: 'C:\Users\M\bzImage'
Detected appx version: 2.4.11.0

[BarsMonster]

Ops, I see custom Kernel. Just rolled back to stock 5.15.167.4-microsoft-standard-WSL2 - exactly same behavior in WSL2 console.

[OneBlue]

Thank you for reporting this @BarsMonster. WSL doesn't process keyboard layouts, this is all handled by Windows.

Do you see the same behavior with let's say a powershell prompt instead of WSL ?

[BarsMonster]

Do you see the same behavior with let's say a powershell prompt instead of WSL ?

No, it works perfectly in powershell.
But the same issue can be seen when running old cmd.exe

[BarsMonster]

To be more precise, I see the issue when opening WSL console via "C:\Windows\System32\wsl.exe ~"

[justus-camp-microsoft]

Hi @BarsMonster, this is unlikely to be a WSL issue and is more likely a Windows or Terminal issue. WSL doesn't do anything specific with keyboard layouts in WSL.