TerminalControl does not produce ENHANCED_KEY in win32 input mode

[krontzo]

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.

[krontzo]

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.

[DHowett]

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]

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,

[krontzo]

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]

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]

WT 1.1.2021.0 works as expected with the setting.

[DHowett]

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:

• Press the arrow keys. This should generate red text on the right pane.
• Send a screenshot of the garbage pane.

[krontzo]

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: mpv-player/mpv#7944

Here you are:

[avih]

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.

[DHowett]

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.

[ghost]

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

Handy links:

• Release Notes
• Store Download

[ghost]

🎉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
• Store Download