starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

TerminalControl does not produce ENHANCED_KEY in win32 input mode #9849

New Issue
Closed
opened 2026-01-31 02:05:25 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 02:05:25 +00:00
Owner
Copy Link

Originally created by @krontzo on GitHub (Jul 25, 2020).

Environment

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19041.0 Microsoft Windows NT 10.0.19041.0

Windows Terminal
Version: 1.1.2021.0

mpv 0.32.0-572-g8fbc4b1737

Steps to reproduce

  1. Play an audio only file as (i.e. only TUI, not GUI):
mpv *.mp3
  1. Press arrow keys to control playback
LEFT and RIGHT
    Seek backward/forward 5 seconds. Shift+arrow does a 1 second exact seek (see --hr-seek).
UP and DOWN
    Seek forward/backward 1 minute. Shift+arrow does a 5 second exact seek (see --hr-seek).

Expected behavior

With previous Windows Terminal versions, the current position was modified as expected.

Actual behavior

LEFT, RIGHT, UP, DOWN keys not sending correct key codes:

[input] No key binding found for key 'KP6'.
A: 00:00:09 / 00:49:16 (0%)
[input] No key binding found for key 'KP4'.
A: 00:00:10 / 00:49:16 (0%)
[input] No key binding found for key 'KP8'.
A: 00:00:10 / 00:49:16 (0%)
[input] No key binding found for key 'KP2'.
A: 00:00:16 / 00:49:16 (1%)

If using powershell 7 without Windows Terminal, the arrow keys work ok. And as a reminder, it was working as expected in previous versions of Windows Terminal. Also works as expected in other shells (cmd.exe, Git Bash) without Windows Terminal.

PS: nvim and vim do not have this issue. Looking for other TUI apps to verify their behavior.

Originally created by @krontzo on GitHub (Jul 25, 2020). # Environment ``` Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.19041.0 Microsoft Windows NT 10.0.19041.0 Windows Terminal Version: 1.1.2021.0 mpv 0.32.0-572-g8fbc4b1737 ``` # Steps to reproduce 1. Play an audio only file as (i.e. only TUI, not GUI): ``` mpv *.mp3 ``` 2. Press arrow keys to control playback ``` LEFT and RIGHT Seek backward/forward 5 seconds. Shift+arrow does a 1 second exact seek (see --hr-seek). UP and DOWN Seek forward/backward 1 minute. Shift+arrow does a 5 second exact seek (see --hr-seek). ``` # Expected behavior With previous Windows Terminal versions, the current position was modified as expected. # Actual behavior LEFT, RIGHT, UP, DOWN keys not sending correct key codes: ``` [input] No key binding found for key 'KP6'. A: 00:00:09 / 00:49:16 (0%) [input] No key binding found for key 'KP4'. A: 00:00:10 / 00:49:16 (0%) [input] No key binding found for key 'KP8'. A: 00:00:10 / 00:49:16 (0%) [input] No key binding found for key 'KP2'. A: 00:00:16 / 00:49:16 (1%) ``` If using powershell 7 without Windows Terminal, the arrow keys work ok. And as a reminder, it was working as expected in previous versions of Windows Terminal. Also works as expected in other shells (cmd.exe, Git Bash) without Windows Terminal. PS: `nvim` and `vim` do not have this issue. Looking for other TUI apps to verify their behavior.
claunia commented 2026-01-31 02:05:26 +00:00
Author
Owner
Copy Link

@krontzo commented on GitHub (Jul 25, 2020):

I just tried alacritty, version 0.4.3, and now I has the same problem; but I didn't update it. With alacritty, it it possible to choose between conpty and winpty. With winpty, mpv works as expected.

I guess that conpty got updated with WT, and it produces the new key codes for mpv .

A workaround for mpv is to create an input.conf and map the new key codes that conpty assigns to arrow keys.

@krontzo commented on GitHub (Jul 25, 2020): I just tried `alacritty`, version 0.4.3, and now I has the same problem; but I didn't update it. With `alacritty`, it it possible to choose between **`conpty`** and **`winpty`**. With `winpty`, mpv works as expected. I guess that **`conpty`** got updated with WT, and it produces the new key codes for mpv . A _workaround_ for mpv is to create an `input.conf` and map the new key codes that **`conpty`** assigns to arrow keys.
claunia commented 2026-01-31 02:05:26 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2020):

KP6/4/8/2 is interesting. Those are not the keys in the traditional T-cluster of arrow keys. Which arrow keys are you pressing? Do you have a number pad? Is numlock enabled?

@DHowett commented on GitHub (Jul 25, 2020): `KP6/4/8/2` is interesting. Those are not the keys in the traditional T-cluster of arrow keys. Which arrow keys are you pressing? Do you have a number pad? Is numlock enabled?
claunia commented 2026-01-31 02:05:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2020):

Just for the record, WT cannot update the version of conpty that comes with Windows. Alacritty is using a version of conpty that was finished almost a year ago. It's missing a bunch of our input changes.

As a workaround, can you see what happens if you put the following setting at the root of your settings file?

"experimental.input.forceVT": true,
@DHowett commented on GitHub (Jul 25, 2020): Just for the record, _WT cannot update the version of conpty that comes with Windows_. Alacritty is using a version of conpty that was finished almost a year ago. It's missing a bunch of our input changes. As a workaround, can you see what happens if you put the following setting at the root of your settings file? ```json "experimental.input.forceVT": true, ```
claunia commented 2026-01-31 02:05:27 +00:00
Author
Owner
Copy Link

@krontzo commented on GitHub (Jul 25, 2020):

KP6/4/8/2 is interesting. Those are not the keys in the traditional T-cluster of arrow keys. Which arrow keys are you pressing? Do you have a number pad? Is numlock enabled?

It's a laptop keyboard. It doesn't have a dedicated number pad. Numlock is not enabled.
The keys are the T-cluster of arrow keys.

Just for the record, WT cannot update the version of conpty that comes with Windows. Alacritty is using a version of conpty that was finished almost a year ago. It's missing a bunch of our input changes.

As a workaround, can you see what happens if you put the following setting at the root of your settings file?

"experimental.input.forceVT": true,

I just installed Windows Terminal v1.0.1811.0 and it works (as it used to).

Reinstalling alacritty to test.

@krontzo commented on GitHub (Jul 25, 2020): > > > `KP6/4/8/2` is interesting. Those are not the keys in the traditional T-cluster of arrow keys. Which arrow keys are you pressing? Do you have a number pad? Is numlock enabled? It's a laptop keyboard. It doesn't have a dedicated number pad. Numlock is not enabled. The keys are the T-cluster of arrow keys. > > > Just for the record, _WT cannot update the version of conpty that comes with Windows_. Alacritty is using a version of conpty that was finished almost a year ago. It's missing a bunch of our input changes. > > As a workaround, can you see what happens if you put the following setting at the root of your settings file? > > ```json > "experimental.input.forceVT": true, > ``` I just installed Windows Terminal v1.0.1811.0 and it works (as it used to). Reinstalling alacritty to test.
claunia commented 2026-01-31 02:05:27 +00:00
Author
Owner
Copy Link

@krontzo commented on GitHub (Jul 25, 2020):

I didn't know that conpty was not updated by WT. Sorry about making that assumption.
I just tested alacritty 0.4.3 and it has the problem, but now I'm not so sure that it didn't have that issue before. I used WT fulltime.

Is it possible to query my system to know conpty's current version and the last time it was updated?
But since WT v1.0.1811.0 does not have the issue, I am clueless about the root of the problem:

Terminal/shell Has the issue? PTY
WT 1.0.18.11.0/any No ConPTY
WT 1.1.2021.0/any Yes ConPTY
alacritty 0.4.3/PS7 Yes ConPTY
alacritty 0.4.3/PS7 No WinPTY
NA / PS7 No NA
NA / WPS No NA
NA / cmd No NA
NA / Git Bash No NA

I'll reinstall WT 1.1.2021.0 to try the suggested setting:

"experimental.input.forceVT": true,
@krontzo commented on GitHub (Jul 25, 2020): I didn't know that conpty was not updated by WT. Sorry about making that assumption. I just tested alacritty 0.4.3 and it has the problem, but now I'm not so sure that it didn't have that issue before. I used WT fulltime. Is it possible to query my system to know conpty's current version and the last time it was updated? But since WT v1.0.1811.0 does not have the issue, I am clueless about the root of the problem: | Terminal/shell | Has the issue? | PTY | |----------------|------------------|-----| | WT 1.0.18.11.0/any | No | ConPTY | | WT 1.1.2021.0/any | **Yes** | ConPTY | | alacritty 0.4.3/PS7 | **Yes** | ConPTY | | alacritty 0.4.3/PS7 | No | WinPTY | | NA / PS7 | No | NA | | NA / WPS | No | NA | | NA / cmd | No | NA | | NA / Git Bash | No | NA | I'll reinstall WT 1.1.2021.0 to try the suggested setting: ``` "experimental.input.forceVT": true, ```
claunia commented 2026-01-31 02:05:27 +00:00
Author
Owner
Copy Link

@krontzo commented on GitHub (Jul 25, 2020):

WT 1.1.2021.0 works as expected with the setting.

@krontzo commented on GitHub (Jul 25, 2020): WT 1.1.2021.0 _works_ as expected with the setting.
claunia commented 2026-01-31 02:05:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 27, 2020):

I'm also quite surprised that alacritty has this problem with ConPTY. We made some input changes (#4999) between Terminal 1.0 and 1.1 that are not available to alacritty yet.

You're using ConPTY 10.0.19041.0 (same as the version of Windows you're using.)

Is this a Windows build of mpv? Can you point me to where you got it?

If you want to help debug what is happening, can you do the following?

  • Set the following settings:
"debugFeatures": true,
"experimental.input.forceVT": false,
  • Open a new tab in Terminal while holding down Left Alt and Right Alt
    • When you do this, you should get two panes, one of which contains weird garbage. Like this:

image

  • Press the arrow keys. This should generate red text on the right pane.
  • Send a screenshot of the garbage pane.
@DHowett commented on GitHub (Jul 27, 2020): I'm also quite surprised that alacritty has this problem with ConPTY. We made some input changes (#4999) between Terminal 1.0 and 1.1 that are not available to alacritty yet. You're using ConPTY 10.0.19041.0 (same as the version of Windows you're using.) Is this a Windows build of mpv? Can you point me to where you got it? If you want to help debug what is happening, can you do the following? * Set the following settings: ``` "debugFeatures": true, "experimental.input.forceVT": false, ``` * Open a new tab in Terminal while holding down <kbd>Left Alt</kbd> **and** <kbd>Right Alt</kbd> * When you do this, you should get two panes, one of which contains weird garbage. Like this: ![image](https://user-images.githubusercontent.com/189190/88598033-5bbd8f00-d01d-11ea-8e34-a8ad26cb10f1.png) * Press the arrow keys. This should generate red text on the right pane. * Send a screenshot of the garbage pane.
claunia commented 2026-01-31 02:05:28 +00:00
Author
Owner
Copy Link

@krontzo commented on GitHub (Jul 28, 2020):

Is this a Windows build of mpv? Can you point me to where you got it?

Yes, it is. From sourceforge: https://sourceforge.net/projects/mpv-player-windows/files

FYI and to help other mpv users of WT: https://github.com/mpv-player/mpv/issues/7944

Here you are:

debug_wt_20200727T2102

@krontzo commented on GitHub (Jul 28, 2020): > Is this a Windows build of mpv? Can you point me to where you got it? Yes, it is. From sourceforge: <https://sourceforge.net/projects/mpv-player-windows/files> FYI and to help other mpv users of WT: https://github.com/mpv-player/mpv/issues/7944 Here you are: ![debug_wt_20200727T2102](https://user-images.githubusercontent.com/1214632/88610553-94c12800-d04c-11ea-98a3-e4cad103649b.png)
claunia commented 2026-01-31 02:05:28 +00:00
Author
Owner
Copy Link

@avih commented on GitHub (Jul 28, 2020):

To demonstrate some difference on how applications recieve arrows input, I wrote this program:

#include <stdio.h>
#include <conio.h>

int main(int argc, char **argv)
{
    int c;
    while ((c = getch()) != '\033' /* ESC */)
        printf("'%c'  0x%02x\n", c < 32 ? '?' : c, c);

    return 0;
}

In windows 10 2004, in normal windows console (cmd.exe), pressing the left arrow (at the inverted T arrows cluster) produces:

'α'  0xe0
'K'  0x4b

While in Windows Terminal 1.1.200629002-release1.1 (command prompt - not powershell) it produces:

'?'  0x00
'K'  0x4b

I'm not very familiar with scancodes (which getch() returns), but some googling suggests that the pair 0xe0 0x4b represents left at the main arrows, while 0x00 0x4b represents left at the keypad.

Caveats:

  • The program was compiled using x86_64-w64-mingw32-gcc (GCC) 9.2.0 (from Cygwin).
  • Windows Terminal was not installed properly - the installer was extracted and WindowsTerminal.exe was executed at the extracted folder (inside CascadiaPackage_1.1.1812.0_x64.msix).
  • mpv uses ReadConsoleInputW and not getch(). mpv does set ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT as well as ENABLE_VIRTUAL_TERMINAL_PROCESSING where supported (e.g. on my system), but it does not set ENABLE_VIRTUAL_TERMINAL_INPUT.

Nevertheless, it does seem to suggest that there's some difference between windows console and windows terminal in how non-VT-input applications recieve arrow keypresses, and additionally with my setup I was able to reproduce the OP's issue when pressing the left arrow - mpv perceiving KP4 at the windows terminal, and LEFT at the windows console.

@avih commented on GitHub (Jul 28, 2020): To demonstrate some difference on how applications recieve arrows input, I wrote this program: ```c #include <stdio.h> #include <conio.h> int main(int argc, char **argv) { int c; while ((c = getch()) != '\033' /* ESC */) printf("'%c' 0x%02x\n", c < 32 ? '?' : c, c); return 0; } ``` In windows 10 2004, in normal windows console (cmd.exe), pressing the left arrow (at the inverted T arrows cluster) produces: ``` 'α' 0xe0 'K' 0x4b ``` While in Windows Terminal 1.1.200629002-release1.1 (command prompt - not powershell) it produces: ``` '?' 0x00 'K' 0x4b ``` I'm not very familiar with scancodes (which `getch()` returns), but some googling suggests that the pair 0xe0 0x4b represents left at the main arrows, while 0x00 0x4b represents left at the keypad. Caveats: - The program was compiled using x86_64-w64-mingw32-gcc (GCC) 9.2.0 (from Cygwin). - Windows Terminal was not installed properly - the installer was extracted and `WindowsTerminal.exe` was executed at the extracted folder (inside `CascadiaPackage_1.1.1812.0_x64.msix`). - mpv uses `ReadConsoleInputW` and not `getch()`. mpv does set `ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT` as well as `ENABLE_VIRTUAL_TERMINAL_PROCESSING` where supported (e.g. on my system), but it does *not* set `ENABLE_VIRTUAL_TERMINAL_INPUT`. Nevertheless, it does seem to suggest that there's some difference between windows console and windows terminal in how non-VT-input applications recieve arrow keypresses, and additionally with my setup I was able to reproduce the OP's issue when pressing the left arrow - mpv perceiving `KP4` at the windows terminal, and `LEFT` at the windows console.
claunia commented 2026-01-31 02:05:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 28, 2020):

Thanks so much. This has been really helpful.

This is the Terminal equivalent of #2397. There's a specific encoding bit that we were missing from the standard arrow keys.

@DHowett commented on GitHub (Jul 28, 2020): Thanks so much. This has been really helpful. This is the Terminal equivalent of #2397. There's a specific encoding bit that we were missing from the standard arrow keys.
claunia commented 2026-01-31 02:05:28 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 13, 2020):

:tada:This issue was addressed in #7106, which has now been successfully released as Windows Terminal v1.1.2233.0.🎉

Handy links:

@ghost commented on GitHub (Aug 13, 2020): :tada:This issue was addressed in #7106, which has now been successfully released as `Windows Terminal v1.1.2233.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.2233.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 02:05:29 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 13, 2020):

:tada:This issue was addressed in #7106, which has now been successfully released as Windows Terminal Preview v1.2.2234.0.🎉

Handy links:

@ghost commented on GitHub (Aug 13, 2020): :tada:This issue was addressed in #7106, which has now been successfully released as `Windows Terminal Preview v1.2.2234.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.2.2234.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9849
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?