mouse events are sent incorrectly in win32-input-mode

[unxed]

Steps to reproduce

1. Compile this test app using gcc under WSL:

#include <termios.h> 
#include <assert.h>
#include <errno.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 


int main()
{
    struct termios _ts = {};
	int _ts_r = tcgetattr(1, &_ts);
	if (_ts_r == 0) {
		struct termios ts_ne = _ts;
		//ts_ne.c_lflag &= ~(ECHO | ECHONL);
		cfmakeraw(&ts_ne);
		if (tcsetattr(1, TCSADRAIN, &ts_ne ) != 0) {
			perror("TTYBackend: tcsetattr");
		}
	}

	fprintf(stderr, "\x1b[?1049h");
	fprintf(stderr, "\x1b[?1000h");
	fprintf(stderr, "\x1b[?1001h");
	fprintf(stderr, "\x1b[?1002h");

	fprintf(stderr, "\x1b[?9001h");

	for (;;) {
		char ch = 0;
		if (read(0, &ch, 1) <= 0) break;
		if (ch <= 0x20 || ch == 0x7f) {
			if (ch == 0x1b) fprintf(stderr, " ");
			fprintf(stderr, "\\x%02x", (unsigned int)(unsigned char)ch);
		} else {
			fprintf(stderr, "%c", ch);
		}
		if (ch == 0x0d) break;
    	if (ch == 0x0a) break;
	}
	fprintf(stderr, "\x1b[?1049l");
	fprintf(stderr, "\x1b[?1000l");
	fprintf(stderr, "\x1b[?1001l");
	fprintf(stderr, "\x1b[?1002l");

	fprintf(stderr, "\x1b[?9001l");

	if (tcsetattr(1, TCSADRAIN, &_ts ) != 0) {
		perror("TTYBackend: tcsetattr");
	}
}

2. Run it under Windows Terminal

3. Move mouse over the terminal window.

Expected Behavior

We should see mouse movement escape sequences (\x1b[M... format)

Actual Behavior

We see win32-input-mode escape sequences (\x1b[A;B;C;D;E;F_ format)

[DHowett]

This is very much probably a corner case we never expected. We didn't actually vet win32 input mode for compatibility with applications (!) as it was originally a stopgap for getting our two terminal emulators to agree on how to handle key events.

This explanation is going to use some terms specific to this codebase.

When we generate a mouse event, we serialize it into a set of key events in InputStateMachineEngine for maximal compatibility with Win32 console applications (which are expecting a Windows API called ReadConsoleInput to return events rather than a string).

It seems we're taking those key events re-encoding them as win32 input events again. From one capture, I see this:

\x1b[0;0;27;1;0;1_   -> \x1b  (pressed)
\x1b[0;0;91;1;0;1_   -> [     (pressed)
\x1b[0;0;77;1;0;1_   -> M     (pressed)
\x1b[56;9;56;1;0;1_  -> 8     (pressed)
\x1b[56;9;56;0;0;1_  -> 8     (released)
\x1b[0;0;27;1;0;1_   -> \x1b  (pressed)
\x1b[0;0;91;1;0;1_   -> [     (pressed)
\x1b[0;0;77;1;0;1_   -> M     (pressed)
\x1b[16;42;0;1;16;1_ -> ???   (pressed)
\x1b[51;4;35;1;16;1_ -> #     (pressed)
\x1b[51;4;35;0;16;1_ -> #     (released)
\x1b[16;42;0;0;0;1_  -> ???   (released)

Which is, of course, entirely bogus.

You're also going to see this for any DSR-CPR, any X11 focus mode, and any other types of answerback.

Excellent find!

[unxed]

Guessed the reason is something like it. Also was very surprised to see other escape sequences packed in the format of win32-input-mode :) I'm glad you're ready to solve it!

As for the use of this protocol in apps, there is a very interesting situation. To date, there are several protocols for extended keyboard support, and each has its own imperfections. kovidgoyal's kitty protocol looks overcomplicated. iTerm2 protocol is strongly tied to MacOS. far2l terminal extensions protocol is not yet very popular outside of far2l (although three applications already support it; I would be glad if you find an opportunity to implement it: it is nice and beautiful, and its keyboard part is based on the same KEY_EVENT_RECORD structure as win32-input-mode).

As a result, I fully admit that it is the win32-input-mode protocol that can become the de facto standard or one of standards.

Yes, I know that there are limitations associated with the fact that virtual scan codes are tied to keyboard layouts that the application on the other side of the terminal does not know anything about. Not a big problem — they are anyway not needed for anything other than distinguishing between the right and left Shift keys as there is a separate field for Unicode characters, and virtual key codes are suitable for implementing hotkeys that work independently of keyboard layout selected.