[Conpty] Add support for mouse input #562

@knuckolls commented on GitHub (Aug 21, 2019):

Just dropping my support for this here, plus a little bit of context. Over the past month I have stopped dual booting and started using the Windows 10 insider builds "fast" ring as my primary personal machine. On that I have wsl2 working perfectly, x410 working perfectly, microsoft terminal working great, visual studio code wsl2 interop working perfectly, and the explorer.exe interop working perfectly.

This mouse input ticket is pretty much the only thing stopping me from calling wsl2 / microsoft terminal a reasonable replacement for having a separate partition / development box. Since some spots here are open source, are there any pointers as to how to see the mouse device inputs from somewhere in /dev or should I just hang tight?

Thanks for all of this though! I really like it otherwise :)

@knuckolls commented on GitHub (Aug 21, 2019): Just dropping my support for this here, plus a little bit of context. Over the past month I have stopped dual booting and started using the Windows 10 insider builds "fast" ring as my primary personal machine. On that I have wsl2 working perfectly, x410 working perfectly, microsoft terminal working great, visual studio code wsl2 interop working perfectly, and the explorer.exe interop working perfectly. This mouse input ticket is pretty much the only thing stopping me from calling wsl2 / microsoft terminal a reasonable replacement for having a separate partition / development box. Since some spots here are open source, are there any pointers as to how to see the mouse device inputs from somewhere in `/dev` or should I just hang tight? Thanks for all of this though! I really like it otherwise :)

claunia commented

@damnskippy commented on GitHub (Aug 23, 2019):

One more vote to say/request that mouse support would be so sweet, and is sorely missed by anyone using tmux, though can sort of get by without it.

@damnskippy commented on GitHub (Aug 23, 2019): One more vote to say/request that mouse support would be so sweet, and is sorely missed by anyone using tmux, though can sort of get by without it.

claunia commented

@r-rojo commented on GitHub (Aug 30, 2019):

Please please please enable mouse support 😄

@r-rojo commented on GitHub (Aug 30, 2019): Please please please enable mouse support 😄

claunia commented

@damnskippy commented on GitHub (Sep 6, 2019):

@DHowett-MSFT, sorry about the nag, is there any plan to fix this any time soon? Seeing labels/priorities assigned on other issues, but this is not one of them, so just checking. Thank you.

@damnskippy commented on GitHub (Sep 6, 2019): @DHowett-MSFT, sorry about the nag, is there any plan to fix this any time soon? Seeing labels/priorities assigned on other issues, but this is not one of them, so just checking. Thank you.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 6, 2019):

@damnskippy Priority is being assigned to things we need to fix in the in-box windows console host (due to internal bug deadlines). This is a huge feature (and requires an appropriately-scaled specification) and while we know we need it for v1.0 we're not actively working on it today.

If we could just "fix" it like a bug, I'd love that -- but it needs a lot more than a fix.

@DHowett-MSFT commented on GitHub (Sep 6, 2019): @damnskippy Priority is being assigned to things we need to fix in the in-box windows console host (due to internal bug deadlines). This is a _huge_ feature (and requires an appropriately-scaled specification) and while we know we need it for v1.0 we're not actively working on it today. If we could just "fix" it like a bug, I'd love that -- but it needs a lot more than a fix.

claunia commented

@tjhowse commented on GitHub (Sep 6, 2019):

Thanks for the update. Your work is appreciated.

@tjhowse commented on GitHub (Sep 6, 2019): Thanks for the update. Your work is appreciated.

claunia commented

@davericher commented on GitHub (Sep 12, 2019):

I love what you are doing here, I do, but until we get mouse support, we have to compliment this terminal with another terminal, somewhat defeating the purpose of this terminal.

@davericher commented on GitHub (Sep 12, 2019): I love what you are doing here, I do, but until we get mouse support, we have to compliment this terminal with another terminal, somewhat defeating the purpose of this terminal.

claunia commented

@rix1337 commented on GitHub (Sep 15, 2019):

Midnight Commander without this is a nightmare.

@rix1337 commented on GitHub (Sep 15, 2019): Midnight Commander without this is a nightmare.

claunia commented

@mdtauk commented on GitHub (Sep 15, 2019):

Mouse Input in general could be useful, say if someone in the community, were to create a DosBox add-in and profile which could run in Windows Terminal.

@mdtauk commented on GitHub (Sep 15, 2019): Mouse Input in general could be useful, say if someone in the community, were to create a DosBox add-in and profile which could run in Windows Terminal.

claunia commented

@chiefjester commented on GitHub (Sep 25, 2019):

I'm a heavy vim user; even I miss mouse support 😢

I just read @cinnamon-msft blog update, seems the team is aiming for 1.0 by the end of this year? Does this mean we get mouse support by the end of the year? If so, is it actively being worked on right now?

@chiefjester commented on GitHub (Sep 25, 2019): I'm a heavy vim user; even I miss mouse support 😢 I just read @cinnamon-msft blog update, seems the team is aiming for 1.0 by the end of this [year](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1909/)? Does this mean we get mouse support by the end of the year? If so, is it actively being worked on right now?

claunia commented

@zadjii-msft commented on GitHub (Sep 25, 2019):

Does this mean we get mouse support by the end of the year?

Maybe, but no hard commits. Estimating how long it takes software to get done is just about as hard as proving P==NP. I'd go so far as to say that the terminal wouldn't be 1.0-ready without this.

If so, is it actively being worked on right now?

Not currently. No one is assigned to the task, and usually when someone on the team bites off a task they'll assign themselves.

@zadjii-msft commented on GitHub (Sep 25, 2019): > Does this mean we get mouse support by the end of the year? Maybe, but no hard commits. Estimating how long it takes software to get done is just about as hard as proving P==NP. I'd go so far as to say that the terminal wouldn't be 1.0-ready without this. > If so, is it actively being worked on right now? Not currently. No one is assigned to the task, and usually when someone on the team bites off a task they'll assign themselves.

claunia commented

@shmuelie commented on GitHub (Sep 25, 2019):

Out of curiosity, is everything needed to do this here? Could an ambitious (read: crazy) developer take it on and make a PR?

@shmuelie commented on GitHub (Sep 25, 2019): Out of curiosity, is everything needed to do this here? Could an ambitious (read: crazy) developer take it on and make a PR?

claunia commented

@zadjii-msft commented on GitHub (Sep 26, 2019):

Sure, someone ambitious absolutely could try this on their own. Where to begin?

First, lets outline some scope. There's a lot of work to do with mouse input, so it'd be best to start small, and work on pieces to get to a complete solution. I think the first thing we should get working is just simple SGR-encoded mouse up/down sequences. We can work on mouse wheel events, then maybe hover, after that, but clicking I think will solve most use cases.

Start by taking a look at InputStateMachineEngine.cpp. The InputStateMachineEngine is responsible for parsing input sent over conpty, and translating it into INPUT_RECORDs. An enterprising young developer would want to modify that class to be able to also parse those mouse sequences, and translate them into INPUT_RECORDs. Once you have the INPUT_RECORDs, call InteractDispatch::WriteInput. This will add those INPUT_RECORDs to the input buffer. Once they are in the input buffer, they'll be delivered to the attached console client application normally.

Things I'd watch out for:

conhost might not insert MouseEvents into the buffer at all unless we're in mouse input mode. If that's the case, then we should make sure to just ignore these sequences as well.
Apps that want mouse input from VT will get not a stream of INPUT_RECORDs, but a stream of characters. At some point in conhost, we attempt to translate those mouse INPUT_RECORDs into a stream of characters, if the attached application is in VT mouse mode. If we do that translation before the mouse events are in the buffer, then doing the above might not work for VT applications (read: wsl). If that's the case, then we'll need to make sure that the translation from mouse INPUT_RECORD to VT-encoded mouse events is done manually for the mouse events generated by the InputStateMachineEngine.
- Looking into it more, that does look like the case. We only translate mouse input for events that were initiated by the window unfortunately. See this code:
  2c8b3243dc/src/interactivity/win32/windowio.cpp (L113-L129)
  terminalMouseInput.HandleMouse will synthesize VT sequences for the client application, but it's only called from the window proc unfortunately. So, we'll need to somehow expose a way for the InputStateMachineEngine to call that (via a new method on InteractDispatch), and if that method fails, then generate the appropriate INPUT_RECORDs.
- Technically, someone could move the terminalMouseInput.HandleMouse call instead to the reading of the InputBuffer, and have it try to translate INPUT_RECORDs right as they're read, but that might be more complicated.

@zadjii-msft commented on GitHub (Sep 26, 2019): Sure, someone ambitious absolutely could try this on their own. Where to begin? First, lets outline some scope. There's a lot of work to do with mouse input, so it'd be best to start small, and work on pieces to get to a complete solution. I think the first thing we should get working is just simple [SGR-encoded](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Extended-coordinates) mouse up/down sequences. We can work on mouse wheel events, then maybe hover, after that, but clicking I think will solve _most_ use cases. Start by taking a look at [InputStateMachineEngine.cpp](https://github.com/microsoft/terminal/blob/master/src/terminal/parser/InputStateMachineEngine.cpp). The `InputStateMachineEngine` is responsible for parsing input sent over conpty, and translating it into `INPUT_RECORD`s. An enterprising young developer would want to modify that class to be able to also parse those mouse sequences, and translate them into `INPUT_RECORD`s. Once you have the `INPUT_RECORD`s, call `InteractDispatch::WriteInput`. This will add those `INPUT_RECORD`s to the input buffer. Once they are in the input buffer, they'll be delivered to the attached console client application normally. Things I'd watch out for: * conhost might not insert MouseEvents into the buffer at all unless we're in mouse input mode. If that's the case, then we should make sure to just ignore these sequences as well. * Apps that want mouse input from VT will get not a stream of `INPUT_RECORD`s, but a stream of characters. At some point in conhost, we attempt to translate those mouse `INPUT_RECORD`s into a stream of characters, if the attached application is in VT mouse mode. If we do that translation _before_ the mouse events are in the buffer, then doing the above might not work for VT applications (read: `wsl`). If that's the case, then we'll need to make sure that the translation from mouse `INPUT_RECORD` to VT-encoded mouse events is done manually for the mouse events generated by the `InputStateMachineEngine`. - Looking into it more, that does look like the case. We only translate mouse input for events that were initiated by the window unfortunately. See this code: https://github.com/microsoft/terminal/blob/2c8b3243dca0c48dd05ecd7b420a7a03b3e19c93/src/interactivity/win32/windowio.cpp#L113-L129 `terminalMouseInput.HandleMouse` will synthesize VT sequences for the client application, but it's only called from the window proc unfortunately. So, we'll need to somehow expose a way for the `InputStateMachineEngine` to call that (via a new method on `InteractDispatch`), and if that method fails, then generate the appropriate `INPUT_RECORD`s. - Technically, someone could move the `terminalMouseInput.HandleMouse` call instead to the reading of the InputBuffer, and have it try to translate `INPUT_RECORD`s right as they're read, but that might be more complicated.

claunia commented

@tungwaiyip commented on GitHub (Dec 11, 2019):

What the deal with this issue? Mouse works perfectly in in the ancient Windows Console. Does it mean I have to stuck with console until this is fixed?

@tungwaiyip commented on GitHub (Dec 11, 2019): What the deal with this issue? Mouse works perfectly in in the ancient Windows Console. Does it mean I have to stuck with console until this is fixed?

claunia commented

@DHowett-MSFT commented on GitHub (Dec 11, 2019):

If you need VT mouse support, yes.

@DHowett-MSFT commented on GitHub (Dec 11, 2019): If you need VT mouse support, yes.

claunia commented

@DHowett-MSFT commented on GitHub (Dec 11, 2019):

Just an FYI to any community members who may have been looking into this (/cc @SamuelEnglard!) we’ve officially booked work on the dev team to do this. I hope we’re not stepping on your toes!

@DHowett-MSFT commented on GitHub (Dec 11, 2019): Just an FYI to any community members who may have been looking into this (/cc @SamuelEnglard!) we’ve officially booked work on the dev team to do this. I hope we’re not stepping on your toes!

claunia commented

2026-01-30 21:55:25 +00:00

@shmuelie commented on GitHub (Dec 11, 2019):

I thought about it, but haven't been able to book my own time so perfect lol!

@shmuelie commented on GitHub (Dec 11, 2019): I thought about it, but haven't been able to book my own time so perfect lol!

claunia commented

@rsinuhe commented on GitHub (Dec 12, 2019):

I was just playing with VSCode with the remote development extensions and found out that the integrated terminal in it actually supports mouse mode in tmux! Panel selection, window selection, panel resizing and scroll wheel support all work. I'm new to these projects though so I don't know if the terminal is part of the open source VS Codium and can be used as a starting point... sorry if this is not really useful info

@rsinuhe commented on GitHub (Dec 12, 2019): I was just playing with VSCode with the remote development extensions and found out that the integrated terminal in it actually supports mouse mode in tmux! Panel selection, window selection, panel resizing and scroll wheel support all work. I'm new to these projects though so I don't know if the terminal is part of the open source VS Codium and can be used as a starting point... sorry if this is not really useful info

claunia commented

2026-01-30 21:55:25 +00:00

@thinkjrs commented on GitHub (Jan 27, 2020):

Just an FYI to any community members who may have been looking into this (/cc @SamuelEnglard!) we’ve officially booked work on the dev team to do this. I hope we’re not stepping on your toes!

@DHowett-MSFT @zadjii-msft @bitcrazed Your communication on this issue herein and elsewhere has been fantastic; this is an exemplar to successfully involve the community in building your software and it shows. Your team(s) (console/WSL/msft-linux) is personally responsible for my business having Windows (non-nix) installs, at all. Keep up the outstanding work 🥇

@thinkjrs commented on GitHub (Jan 27, 2020): > Just an FYI to any community members who may have been looking into this (/cc @SamuelEnglard!) we’ve officially booked work on the dev team to do this. I hope we’re not stepping on your toes! @DHowett-MSFT @zadjii-msft @bitcrazed Your communication on this issue herein and elsewhere has been fantastic; this is an exemplar to successfully involve the community in building your software and it shows. Your team(s) (console/WSL/msft-linux) is personally responsible for my business having Windows (non-nix) installs, at all. Keep up the outstanding work 🥇

claunia commented

2026-01-30 21:55:25 +00:00

@bitcrazed commented on GitHub (Jan 28, 2020):

@thinkjrs Many thanks for your kind words.

And our sincerest thanks to you and everyone in our community who runs & tests / files bugs / submits asks, ideas, and pull-requests for Terminal, Cascadia Code, WSL, etc. Your feedback directly influences us as we prioritize work, and plan and design features.

We weren't kidding when we say that we build these features for and with our community 😜

@bitcrazed commented on GitHub (Jan 28, 2020): @thinkjrs Many thanks for your kind words. And our sincerest thanks to you and everyone in our community who runs & tests / files bugs / submits asks, ideas, and pull-requests for Terminal, Cascadia Code, WSL, etc. Your feedback directly influences us as we prioritize work, and plan and design features. We weren't kidding when we say that we build these features for and with our community 😜

claunia commented

2026-01-30 21:55:26 +00:00

@dmxt commented on GitHub (Feb 10, 2020):

What is the process? Are there any functional mouses in WSL? I.e. tmux panel switching, clicking to change channel/server in weechat&irssi, (n)vim clicks, aptitude clicking, htop clicking, etc.

@dmxt commented on GitHub (Feb 10, 2020): What is the process? Are there any functional mouses in WSL? I.e. `tmux` panel switching, clicking to change channel/server in `weechat`&`irssi`, `(n)vim` clicks, `aptitude` clicking, `htop` clicking, etc.

claunia commented

2026-01-30 21:55:26 +00:00

@offero commented on GitHub (Feb 10, 2020):

What is the process? Are there any functional mouses in WSL? I.e. tmux panel switching, clicking to change channel/server in weechat&irssi, (n)vim clicks, aptitude clicking, htop clicking, etc.

@dmxt Currently I use wsltty which has been the most compatible of all the terminal options for me. I look forward to switching to Terminal once some of these features come around.

@offero commented on GitHub (Feb 10, 2020): > What is the process? Are there any functional mouses in WSL? I.e. `tmux` panel switching, clicking to change channel/server in `weechat`&`irssi`, `(n)vim` clicks, `aptitude` clicking, `htop` clicking, etc. @dmxt Currently I use wsltty which has been the most compatible of all the terminal options for me. I look forward to switching to Terminal once some of these features come around.

claunia commented

2026-01-30 21:55:26 +00:00

@dmxt commented on GitHub (Feb 23, 2020):

What is the process? Are there any functional mouses in WSL? I.e. tmux panel switching, clicking to change channel/server in weechat&irssi, (n)vim clicks, aptitude clicking, htop clicking, etc.

@dmxt Currently I use wsltty which has been the most compatible of all the terminal options for me. I look forward to switching to Terminal once some of these features come around.

I agree with your comment, after trying out all terminal emulators known to the public for Windows in the past several years, for now at the time of writing, wsltty is the best out there. Their official repo is great as well, they have a wonderful guide for me to get started out in a speedy manner. You couldn't ask for better with witty, it got full mouse support with no hiccups throughout various different workflows and tools.

I noticed the slight latency in I/O and I think it's the bottleneck of the WSL1 system. I'm on bare-metal Linux and there's 0ms latency with mouse input.

@dmxt commented on GitHub (Feb 23, 2020): > > What is the process? Are there any functional mouses in WSL? I.e. `tmux` panel switching, clicking to change channel/server in `weechat`&`irssi`, `(n)vim` clicks, `aptitude` clicking, `htop` clicking, etc. > > @dmxt Currently I use wsltty which has been the most compatible of all the terminal options for me. I look forward to switching to Terminal once some of these features come around. I agree with your comment, after trying out all terminal emulators known to the public for Windows in the past several years, for now at the time of writing, wsltty is the best out there. Their official repo is great as well, they have a wonderful guide for me to get started out in a speedy manner. You couldn't ask for better with witty, it got full mouse support with no hiccups throughout various different workflows and tools. I noticed the slight latency in I/O and I think it's the bottleneck of the WSL1 system. I'm on bare-metal Linux and there's 0ms latency with mouse input.

claunia commented

@iivmok commented on GitHub (Feb 26, 2020):

@dmxt @offero I have had success with XShell (real command line from experimental features, or ssh into WSL) - has mouse support etc, just FYI. Also apps that needs mouse support badly are midnight commander and micro editor

@iivmok commented on GitHub (Feb 26, 2020): @dmxt @offero I have had success with XShell (real command line from experimental features, or ssh into WSL) - has mouse support etc, just FYI. Also apps that needs mouse support badly are [midnight commander](https://midnight-commander.org/) and [micro editor](https://micro-editor.github.io/)

claunia commented

@SiarheiKuchukBelitsoft commented on GitHub (Apr 14, 2020):

Please take a look how it is solved in ConEmu

@SiarheiKuchukBelitsoft commented on GitHub (Apr 14, 2020): Please take a look how it is solved in ConEmu

claunia commented

@kvnxiao commented on GitHub (May 20, 2020):

Any roadmap or timeline for when exactly this will hopefully be implemented? Seems like quite an important feature to release. It's kind of surprising to me that v1.0 is being released without this being resolved. I guess versioning doesn't mean anything nowadays.

@kvnxiao commented on GitHub (May 20, 2020): Any roadmap or timeline for when exactly this will hopefully be implemented? Seems like quite an important feature to release. It's kind of surprising to me that v1.0 is being released without this being resolved. I guess versioning doesn't mean anything nowadays.

claunia commented

@fat0troll commented on GitHub (May 20, 2020):

@kvnxiao in latest Microsoft Store version of Windows Terminal mouse input is supported (at least in Vim), as far as I can tell

@fat0troll commented on GitHub (May 20, 2020): @kvnxiao in latest Microsoft Store version of Windows Terminal mouse input is supported (at least in Vim), as far as I can tell

claunia commented

@kvnxiao commented on GitHub (May 20, 2020):

@fat0troll As far as I can tell, this is definitely not the case. Even in vim with set mouse=a, mouse input works on old conhost but not Windows Terminal 1.0.1401.0.

@kvnxiao commented on GitHub (May 20, 2020): @fat0troll As far as I can tell, this is definitely not the case. Even in vim with `set mouse=a`, mouse input works on old conhost but not Windows Terminal 1.0.1401.0.

claunia commented

@fat0troll commented on GitHub (May 20, 2020):

set nocompatible
syntax on
set number
set mouse=a
set backspace=indent,eol,start

With that vim config I can click inside vim's window and cursor will move to place where I've clicked. 1.0.1401.0, Windows build 18368.836 (if it have any effect on this).

@fat0troll commented on GitHub (May 20, 2020): ``` set nocompatible syntax on set number set mouse=a set backspace=indent,eol,start ``` With that vim config I can click inside vim's window and cursor will move to place where I've clicked. 1.0.1401.0, Windows build 18368.836 (if it have any effect on this).

claunia commented

@DHowett commented on GitHub (May 20, 2020):

@kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode.

We explicitly implemented this for all VT applications that want to receive mouse input.

I guess versioning doesn't mean anything nowadays.

There's no need to be unkind.

@DHowett commented on GitHub (May 20, 2020): @kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode. We explicitly implemented this for all VT applications that want to receive mouse input. > I guess versioning doesn't mean anything nowadays. There's no need to be unkind.

claunia commented

@kvnxiao commented on GitHub (May 20, 2020):

Regarding vim, I've attempted it using neovim built for windows as a windows executable. If others are saying that mouse support does work for vim (e.g. through ssh / wsl, etc.), then I am not doubting you, but this shows that "full" support doesn't exist as of yet, which poses a more specific question:

What would be left in the roadmap for "full" mouse support in comparison with what conhost is currently capable of?

I am speaking in terms of wanting to launch generic terminal-based applications that support mouse input (and do work in conhost) through WT. For example, running several text-based/terminal user-interface applications built directly as a windows executable. These do work fine when double-clicked on to run, which resort to using conhost, but when ran through Windows Terminal they end up with just the mouse selecting the text displayed.

@niklaskorz What is the point of upvoting and downvoting the aforementioned comments when people like me have relevant questions pertaining to this topic, that may or may not still be unresolved?

@kvnxiao commented on GitHub (May 20, 2020): Regarding vim, I've attempted it using neovim built for windows as a windows executable. If others are saying that mouse support does work for vim (e.g. through ssh / wsl, etc.), then I am not doubting you, but this shows that "full" support doesn't exist as of yet, which poses a more specific question: What would be left in the roadmap for "full" mouse support in comparison with what conhost is currently capable of? I am speaking in terms of wanting to launch generic terminal-based applications that support mouse input (and do work in conhost) through WT. For example, running several text-based/terminal user-interface applications built directly as a windows executable. These do work fine when double-clicked on to run, which resort to using conhost, but when ran through Windows Terminal they end up with just the mouse selecting the text displayed. @niklaskorz What is the point of upvoting and downvoting the aforementioned comments when people like me have relevant questions pertaining to this topic, that may or may not still be unresolved?

claunia commented

@DHowett commented on GitHub (May 20, 2020):

You’re totally right. This workitem, which you have correctly identified as being for Win32 console applications receiving mouse events from any terminal, is slated for “terminal 1.x” (milestone), which indicates that we want to tackle it between now and 2.0. I don’t have a finer-grained estimate than that.

@DHowett commented on GitHub (May 20, 2020): You’re totally right. This workitem, which you have correctly identified as being for Win32 console applications receiving mouse events from any terminal, is slated for “terminal 1.x” (milestone), which indicates that we want to tackle it between now and 2.0. I don’t have a finer-grained estimate than that.

claunia commented

@kvnxiao commented on GitHub (May 20, 2020):

Thanks for the clarification! A bit sad that this workitem wasn't able to be competed for 1.0 but I'm eagerly awaiting for when it does, and hopefully it won't be too long of a wait 😀.

@kvnxiao commented on GitHub (May 20, 2020): Thanks for the clarification! A bit sad that this workitem wasn't able to be competed for 1.0 but I'm eagerly awaiting for when it does, and hopefully it won't be too long of a wait 😀.

claunia commented

@tig commented on GitHub (May 22, 2020):

FIWW, in case you weren't aware of it, the new Powershell Out-ConsoleGridView (https://github.com/PowerShell/GraphicalTools) is a killer test case for this. See Mouse related tracking bug there: https://github.com/PowerShell/GraphicalTools/issues/95

It is built on top of Terminal.Gui (https://github.com/tig/gui.cs).

In addition, we just built a new sample app for Terminal.Gui that y'all should be able to use to test mouse support as it comes to life in WT.

Really looking forward to it!

@tig commented on GitHub (May 22, 2020): FIWW, in case you weren't aware of it, the new Powershell `Out-ConsoleGridView` (https://github.com/PowerShell/GraphicalTools) is a killer test case for this. See Mouse related tracking bug there: https://github.com/PowerShell/GraphicalTools/issues/95 It is built on top of `Terminal.Gui` (https://github.com/tig/gui.cs). In addition, we just built a new sample app for `Terminal.Gui` that y'all should be able to use to test mouse support as it comes to life in WT. Really looking forward to it!

claunia commented

@tig commented on GitHub (Jun 13, 2020):

Is there any way I can help get this issue fixed? It is a real bummer for GUI console apps built with Terminal.Gui (https://github.com/tig/gui.cs).

@tig commented on GitHub (Jun 13, 2020): Is there any way I can help get this issue fixed? It is a real bummer for GUI console apps built with Terminal.Gui (https://github.com/tig/gui.cs).

claunia commented

@ipcjs commented on GitHub (Jun 26, 2020):

@kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode.

We explicitly implemented this for all VT applications that want to receive mouse input.

I guess versioning doesn't mean anything nowadays.

There's no need to be unkind.

How can i update build-in openssh to latest version?

@ipcjs commented on GitHub (Jun 26, 2020): > @kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode. > > We explicitly implemented this for all VT applications that want to receive mouse input. > > > I guess versioning doesn't mean anything nowadays. > > There's no need to be unkind. How can i update build-in openssh to latest version?

claunia commented

@thochra commented on GitHub (Jun 26, 2020):

@kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode.
We explicitly implemented this for all VT applications that want to receive mouse input.

I guess versioning doesn't mean anything nowadays.

There's no need to be unkind.

How can i update build-in openssh to latest version?

I guess you're looking for something described in this blog post (Openssh install from chocolatey) : https://blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to-openssh-portable/

@thochra commented on GitHub (Jun 26, 2020): > > @kvnxiao I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode. > > We explicitly implemented this for all VT applications that want to receive mouse input. > > > I guess versioning doesn't mean anything nowadays. > > > > > > There's no need to be unkind. > > How can i update build-in openssh to latest version? I guess you're looking for something described in this blog post (Openssh install from chocolatey) : https://blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to-openssh-portable/

claunia commented

@cgsdev0 commented on GitHub (Sep 11, 2020):

I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode.

We explicitly implemented this for all VT applications that want to receive mouse input.

@DHowett from this context, it sounds like using OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5 would be expected to work?

I'm using the Terminal preview build to SSH to an Ubuntu machine with tmux mouse mode enabled, but my mouse inputs still seem to only be controlling the terminal itself.

I've also tried upgrading the server to OpenSSH 8.0, but that didn't help either.

Is this issue still blocking that sort of thing from working?

@cgsdev0 commented on GitHub (Sep 11, 2020): > I'm going to guess you're using OpenSSH_For_Windows_7.7. There's a bug in it (resolved in 8.x) that prevents it from working for mouse mode. > > We explicitly implemented this for all VT applications that want to receive mouse input. @DHowett from this context, it sounds like using `OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5` would be expected to work? I'm using the Terminal preview build to SSH to an Ubuntu machine with tmux mouse mode enabled, but my mouse inputs still seem to only be controlling the terminal itself. I've also tried upgrading the server to OpenSSH 8.0, but that didn't help either. Is this issue still blocking that sort of thing from working?

claunia commented

@DHowett commented on GitHub (Sep 11, 2020):

Ah, the x in 8.x might be 1. I was not aware that they released an 8.0 build.

@DHowett commented on GitHub (Sep 11, 2020): Ah, the `x` in 8.x might be 1. I was not aware that they released an 8.0 build.

claunia commented

@cgsdev0 commented on GitHub (Sep 11, 2020):

Ah, the x in 8.x might be 1. I was not aware that they released an 8.0 build.

~~I'll give that a shot. Thanks for the incredibly fast response!~~

It works! Amazing, thank you!

@cgsdev0 commented on GitHub (Sep 11, 2020): > Ah, the x in 8.x might be 1. I was not aware that they released an 8.0 build. ~~I'll give that a shot. Thanks for the incredibly fast response!~~ It works! Amazing, thank you!

claunia commented

@Hamayama commented on GitHub (Oct 31, 2020):

I began to understand this issue.

Sadly, MS doesn't implement mouse input function of Win32 API on Windows Terminal yet.
(Only VT escape sequence is supported.)

I tried to replace ReadConsoleInputW and PeekConsoleInputW in my application
to work with mouse on Windows Terminal.

First, I run the following code.

SetConsoleMode(hin,  ENABLE_VIRTUAL_TERMINAL_INPUT);
SetConsoleMode(hout, ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING);
const char *vt_mouse_input_enable_cmd  = "\x1b[?1003;1006h";
DWORD written;
WriteConsoleA(hout, vt_mouse_input_enable_cmd, strlen(vt_mouse_input_enable_cmd), &written, NULL);

Then, mouse input can be received as VT escape sequence (sgr-1006) (e.g. \x1b[<0;10;20M ).

But, another problem occurred.

Some key input (such as arrow keys) are also received as VT escape sequence (e.g. \x1b[A ).

I tried to convert these unwanted VT escape sequece to key event of win32 API,
but this is incomplete.
(virtual key code and virtual scan code casually become zero, etc.)

My source code is here.
https://gist.github.com/Hamayama/6add968870269f2426716fad79724b31
( PDC_read_console_input_w and PDC_peek_console_input_w are alternative functions. )

I want a method to disable VT escape sequece except for mouse input.

for example

const char *vt_key_input_disable_cmd = "\x1b[?9XXXl";
DWORD written;
WriteConsoleA(hout, vt_key_input_disable_cmd, strlen(vt_key_input_disable_cmd), &written, NULL);

or

SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_MOUSE_INPUT_ONLY);

But, this might be a wrong idea for the future ...

@Hamayama commented on GitHub (Oct 31, 2020): I began to understand this issue. Sadly, MS doesn't implement mouse input function of Win32 API on Windows Terminal yet. (Only VT escape sequence is supported.) I tried to replace ReadConsoleInputW and PeekConsoleInputW in my application to work with mouse on Windows Terminal. First, I run the following code. ``` SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_INPUT); SetConsoleMode(hout, ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING); const char *vt_mouse_input_enable_cmd = "\x1b[?1003;1006h"; DWORD written; WriteConsoleA(hout, vt_mouse_input_enable_cmd, strlen(vt_mouse_input_enable_cmd), &written, NULL); ``` Then, mouse input can be received as VT escape sequence (sgr-1006) (e.g. `\x1b[<0;10;20M` ). But, another problem occurred. Some key input (such as arrow keys) are also received as VT escape sequence (e.g. `\x1b[A` ). I tried to convert these unwanted VT escape sequece to key event of win32 API, but this is incomplete. (virtual key code and virtual scan code casually become zero, etc.) My source code is here. https://gist.github.com/Hamayama/6add968870269f2426716fad79724b31 ( PDC_read_console_input_w and PDC_peek_console_input_w are alternative functions. ) I want a method to disable VT escape sequece except for mouse input. for example ``` const char *vt_key_input_disable_cmd = "\x1b[?9XXXl"; DWORD written; WriteConsoleA(hout, vt_key_input_disable_cmd, strlen(vt_key_input_disable_cmd), &written, NULL); ``` or ``` SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_MOUSE_INPUT_ONLY); ``` But, this might be a wrong idea for the future ...

claunia commented

@o-sdn-o commented on GitHub (Nov 24, 2020):

I found that there is no tracking of mouse movement in src/terminal/parser/InputStateMachineEngine.cpp: 391 (translation of SGR VT-sequences into INPUT_RECORDs).

In other words, the Terminal sends VT-sequences for ConPTY, but ConPTY only monitors the state of the mouse buttons. Changes in mouse coordinates are ignored:

src/terminal/parser/InputStateMachineEngine.cpp: 391:

success = _UpdateSGRMouseButtonState(id, firstParameter, buttonState, eventFlags);
success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);

With the current state of support for mouse input, the following option is possible.

You can add coordinate tracking and mouse movement will start working in classic console applications.

src/terminal/parser/InputStateMachineEngine.hpp: 172:

+ size_t _mouseColumn = 0;
+ size_t _mouseLine = 0;

src/terminal/parser/InputStateMachineEngine.cpp: 391:

- success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);
+ auto mouseColumn = parameters.at(1).value_or(0);
+ auto mouseLine = parameters.at(2).value_or(0);
+ auto isMoved = mouseColumn! = _mouseColumn || mouseLine! = _mouseLine;
+ if (isMoved)
+ {
+     _mouseColumn = mouseColumn;
+     _mouseLine = mouseLine;
+ }
+ success = (success || isMoved) && _WriteMouseEvent(mouseColumn, mouseLine, buttonState, modifierState, eventFlags);

Note: Before starting a classic console application, you need to request mouse tracking in SGR format:

Windows PowerShell

PS C:\Users> [char]0x1b + "[?1003;1004;1006h"

Command Prompt

C:\Users> echo Ctrl+[[?1003;1004;1006h

Parameters

1003 - ANY_EVENT_MOUSE_MODE
1004 - any unsupported mode (e.g. 1001 or 9999) to forward the sequence through ConPTY to the Terminal itself
1006 - SGR_EXTENDED_MODE

as a result, the Terminal will start sending mouse events to ConpTY, which will start generating INPUT_RECORDs for the classic console application.

@o-sdn-o commented on GitHub (Nov 24, 2020): I found that there is no tracking of mouse movement in `src/terminal/parser/InputStateMachineEngine.cpp: 391` (translation of SGR VT-sequences into `INPUT_RECORD`s). In other words, the Terminal sends VT-sequences for ConPTY, but ConPTY only monitors the state of the mouse buttons. Changes in mouse coordinates are ignored: `src/terminal/parser/InputStateMachineEngine.cpp: 391`: ``` success = _UpdateSGRMouseButtonState(id, firstParameter, buttonState, eventFlags); success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags); ``` With the current state of support for mouse input, the following option is possible. You can add coordinate tracking and mouse movement will start working in classic console applications. `src/terminal/parser/InputStateMachineEngine.hpp: 172`: ``` + size_t _mouseColumn = 0; + size_t _mouseLine = 0; ``` `src/terminal/parser/InputStateMachineEngine.cpp: 391`: ``` - success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags); + auto mouseColumn = parameters.at(1).value_or(0); + auto mouseLine = parameters.at(2).value_or(0); + auto isMoved = mouseColumn! = _mouseColumn || mouseLine! = _mouseLine; + if (isMoved) + { + _mouseColumn = mouseColumn; + _mouseLine = mouseLine; + } + success = (success || isMoved) && _WriteMouseEvent(mouseColumn, mouseLine, buttonState, modifierState, eventFlags); ``` Note: Before starting a classic console application, you need to request mouse tracking in SGR format: #### Windows PowerShell `PS C:\Users> [char]0x1b + "[?1003;1004;1006h"` #### Command Prompt `C:\Users> echo `<kbd>Ctrl+[</kbd>`[?1003;1004;1006h` ##### Parameters - `1003` - ANY_EVENT_MOUSE_MODE - `1004` - any unsupported mode (e.g. `1001` or `9999`) to forward the sequence through ConPTY to the Terminal itself - `1006` - SGR_EXTENDED_MODE as a result, the Terminal will start sending mouse events to ConpTY, which will start generating `INPUT_RECORD`s for the classic console application.

claunia commented

@DHowett commented on GitHub (Nov 24, 2020):

Good catch. We'll have to make sure we fix that when we actually move to support this 😄

@DHowett commented on GitHub (Nov 24, 2020): Good catch. We'll have to make sure we fix that when we actually move to support this :smile:

claunia commented

@igoradamenko commented on GitHub (Dec 22, 2020):

Hey folks!

Sorry to interrupt, but is it the right issue to track the bug where I can't scroll less or git log output? I'm using WSL 2 with Ubuntu 20.04 inside, and when I do less long-file or git log I can't scroll the output using my mouse.

Not sure, should I track this issue or create a new one?

@igoradamenko commented on GitHub (Dec 22, 2020): Hey folks! Sorry to interrupt, but is it the right issue to track the bug where I can't scroll `less` or `git log` output? I'm using WSL 2 with Ubuntu 20.04 inside, and when I do `less long-file` or `git log` I can't scroll the output using my mouse. Not sure, should I track this issue or create a new one?

claunia commented

@d3x0r commented on GitHub (Dec 22, 2020):

@iamakulov not really - though maybe I can give you a fix.

TERM gets set to xterm-256color
less doesn't understand this, and would prefer it to be TERM=xterm
(maybe)? seems to be working for me today.... but I think when I connected to centos i had issues; no, that's working too... somewhere something complained about the TERM setting that gave me a clue.
otherwise - no, your issue is nothing to do with mouse input.

@d3x0r commented on GitHub (Dec 22, 2020): @iamakulov not really - though maybe I can give you a fix. TERM gets set to xterm-256color `less` doesn't understand this, and would prefer it to be `TERM=xterm` (maybe)? seems to be working for me today.... but I think when I connected to centos i had issues; no, that's working too... somewhere something complained about the TERM setting that gave me a clue. otherwise - no, your issue is nothing to do with mouse input.

claunia commented

@paddywaan commented on GitHub (Jan 13, 2021):

Hi, I just want to double check that I don't post a duplicate issue, and this sounds awfully familiar to my inability to have windows terminal + OpenSSH to register mouse events. My issue definitely isn't specific to an application such as vim, as htop and other utilities also appear to be ignoring VT input. Is someone able to confirm that this is the same issue? Thanks.

@paddywaan commented on GitHub (Jan 13, 2021): Hi, I just want to double check that I don't post a duplicate issue, and this sounds awfully familiar to my inability to have windows terminal + OpenSSH to register mouse events. My issue definitely isn't specific to an application such as vim, as htop and other utilities also appear to be ignoring VT input. Is someone able to confirm that this is the same issue? Thanks.

claunia commented

@DHowett commented on GitHub (Jan 13, 2021):

@paddywaan OpenSSH 7.7 as shipped in Windows doesn’t pass along the mouse events that applications request. Upgrade to 8.2, from the repository at https://github.com/powershell/win32-openssh.

@DHowett commented on GitHub (Jan 13, 2021): @paddywaan OpenSSH 7.7 as shipped in Windows doesn’t pass along the mouse events that applications request. Upgrade to 8.2, from the repository at https://github.com/powershell/win32-openssh.

claunia commented

@paddywaan commented on GitHub (Jan 13, 2021):

Is that a typo or a mistake? I've installed the latest v8.1 from the releases, as well as rebooted however the issue persists. I've found: https://github.com/PowerShell/Win32-OpenSSH/issues/1158 yet this does not yield any new resolutions. Sorry to clutter this discussion, I will post this same message in the thread I've linked.

@paddywaan commented on GitHub (Jan 13, 2021): Is that a typo or a mistake? I've installed the latest v8.1 from the releases, as well as rebooted however the issue persists. I've found: https://github.com/PowerShell/Win32-OpenSSH/issues/1158 yet this does not yield any new resolutions. Sorry to clutter this discussion, I will post this same message in the thread I've linked.

claunia commented

@T1MOXA commented on GitHub (Feb 24, 2021):

Can confirm, mouse clicks works fine with OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2
from
https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v8.1.0.0p1-Beta

UPD.
But it's quite buggy

@T1MOXA commented on GitHub (Feb 24, 2021): Can confirm, mouse clicks works fine with `OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2` from https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v8.1.0.0p1-Beta ![image](https://user-images.githubusercontent.com/19938629/109054412-82909080-76e6-11eb-96c8-d3700ecd6b5e.png) UPD. But it's quite buggy

claunia commented

@d3x0r commented on GitHub (Feb 24, 2021):

So why is openssh in ms terminal so special?
Can confirm it still doesn't work with other native console apps; it just selects.
Hmm - is there an unbind I have to do maybe like for ctrl-c,v and F11?

@d3x0r commented on GitHub (Feb 24, 2021): So why is openssh in ms terminal so special? Can confirm it still doesn't work with other native console apps; it just selects. Hmm - is there an unbind I have to do maybe like for ctrl-c,v and F11? ![image](https://user-images.githubusercontent.com/1909610/109059880-99f55c80-7699-11eb-9360-f502a032da97.png)

claunia commented

@zadjii-msft commented on GitHub (Feb 24, 2021):

If you're using ssh (even the win32-openssh version), then you're probably hitting the "VT mouse mode" input path, rather than the Win32 input path. VT mouse mode is supported in the Terminal, while win32-style mouse mode is not yet.

@zadjii-msft commented on GitHub (Feb 24, 2021): If you're using `ssh` (even the win32-openssh version), then you're probably hitting the "VT mouse mode" input path, rather than the Win32 input path. VT mouse mode _is_ supported in the Terminal, while win32-style mouse mode is not yet.

claunia commented

@d3x0r commented on GitHub (Feb 25, 2021):

Ok; what is the API for 'VT mouse mode'?

@d3x0r commented on GitHub (Feb 25, 2021): Ok; what is the API for 'VT mouse mode'?

claunia commented

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking

@christianparpart commented on GitHub (Feb 25, 2021):

Generally, search for mouse keyword in this whole document.

You need to send a DECSM for the given mouse mode you are interested in,
and then you get events via stdin until you disable this mode via DECRM
again.

@christianparpart commented on GitHub (Feb 25, 2021): https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking Generally, search for mouse keyword in this whole document. You need to send a DECSM for the given mouse mode you are interested in, and then you get events via stdin until you disable this mode via DECRM again.

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

I'm confused by this topic. Upon first and second reading, it seemed that the issue was fixed and awaiting updated OpenSSH delivery by Microsoft as seen here: https://github.com/PowerShell/Win32-OpenSSH/issues/1310

I wasn't concerned about VT mouse support at first. I was just trying to get my slightly unusual escape codes configured for Windows Terminal. Based on having seen this topic, I went to install MSYS2, and used its pacman to obtain ssh, which when using this ssh (instead of calling ssh from PowerShell), my configured sendInput key binds for Windows Terminal began to work!

At this point the next step is VT mouse support. I don't rely on mouse, but I do end up using it extensively for things such as clicking and scrolling different panes in tmux. Mouse support still doesn't work! The key to this comment is that even in extensive testing without involving any SSH, I still cannot make Windows Terminal enter VT mouse mode.

I'm running:

Windows Terminal Preview Version: 1.8.1032.0

and testing by:

Running neovim obtained here https://github.com/neovim/neovim/releases/download/nightly/nvim-win64.zip No mouse responsive behavior is observed. This is whether I run it from powershell, run it as a profile's command line, or run it from MSYS2 bash.
echo -e "\e[?1000h". This does not work at all. When I run this in Putty, it will begin to emit mouse events in code. But it has no effect in Windows Terminal in bash. This appears to be the most basic possible way to

specify parameter 1000 to DECSET

As explained in the XTerm control sequences documentation.

@unphased commented on GitHub (Apr 16, 2021): I'm confused by this topic. Upon first and second reading, it seemed that the issue was fixed and awaiting updated OpenSSH delivery by Microsoft as seen here: https://github.com/PowerShell/Win32-OpenSSH/issues/1310 I wasn't concerned about VT mouse support at first. I was just trying to get my slightly unusual escape codes configured for Windows Terminal. Based on having seen this topic, I went to install MSYS2, and used its pacman to obtain `ssh`, which when using this ssh (instead of calling ssh from PowerShell), my configured sendInput key binds for Windows Terminal began to work! At this point the next step is VT mouse support. I don't rely on mouse, but I do end up using it extensively for things such as clicking and scrolling different panes in tmux. Mouse support still doesn't work! The key to this comment is that even in extensive testing without involving any SSH, I still cannot make Windows Terminal enter VT mouse mode. I'm running: > Windows Terminal Preview Version: 1.8.1032.0 and testing by: - Running neovim obtained here https://github.com/neovim/neovim/releases/download/nightly/nvim-win64.zip No mouse responsive behavior is observed. This is whether I run it from powershell, run it as a profile's command line, or run it from MSYS2 bash. - `echo -e "\e[?1000h"`. This does not work at all. When I run this in Putty, it will begin to emit mouse events in code. But it has no effect in Windows Terminal in bash. This appears to be the most basic possible way to > specify parameter 1000 to DECSET As explained in the XTerm control sequences documentation.

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

Wow! OK I have found something out. I enabled :set mouse=a in nvim and it is working, both directly running as command line, and under powershell. So this is working after all! All I have to do now is to find out how to get SSH to behave!!

@unphased commented on GitHub (Apr 16, 2021): Wow! OK I have found something out. I enabled `:set mouse=a` in nvim and it is working, both directly running as command line, and under powershell. So this is working after all! All I have to do now is to find out how to get SSH to behave!!

claunia commented

2026-01-30 21:55:33 +00:00

@unphased commented on GitHub (Apr 16, 2021):

Pretty much just stuck here though. It's hard to work out what nvim is doing differently, but set mouse=a definitely doesn't work in the vim that I got via MSYS2. And no amount of coaxing works for echo -e "\e[?1000h" either still. I suspect that there's something windows-specific (at least there is in the neovim code) at play.

@unphased commented on GitHub (Apr 16, 2021): Pretty much just stuck here though. It's hard to work out what nvim is doing differently, but `set mouse=a` definitely doesn't work in the vim that I got via MSYS2. And no amount of coaxing works for `echo -e "\e[?1000h"` either still. I suspect that there's something windows-specific (at least there is in [the neovim code](https://github.com/neovim/neovim/blob/8e496b9dfd5b644f06536afea63e3088b9d83cf8/src/nvim/tui/tui.c#L1033)) at play.

claunia commented

@DHowett commented on GitHub (Apr 16, 2021):

So, there’s a little trick you can do to see what Terminal is receiving from the client process (roughly. There’s some translation going on, but when an app sends DECSET/DECRST it is unmodified and passes directly through. Translation only happens for things that would manipulate the screen) and what you’re sending.

Add the global setting (near the top of your JSON file) "debugFeaturesEnabled": true
Hold down left and right Alt when you open a new tab (doesn’t work with panes)

This should, gods willing, open the “debug tap”. I hope I remembered the key name correct.

This is the only debug feature that is toggled by that setting right now, so it is safe to leave on.

@DHowett commented on GitHub (Apr 16, 2021): So, there’s a little trick you can do to see what Terminal is receiving from the client process (roughly. There’s some translation going on, but when an app sends DECSET/DECRST it is unmodified and passes directly through. Translation only happens for things that would manipulate the screen) and what you’re sending. 1. Add the global setting (near the top of your JSON file) `"debugFeaturesEnabled": true` 2. Hold down _left and right Alt_ when you open a new tab (doesn’t work with panes) This should, gods willing, open the “debug tap”. I hope I remembered the key name correct. This is the only debug feature that is toggled by that setting right now, so it is safe to leave on.

claunia commented

2026-01-30 21:55:33 +00:00

@unphased commented on GitHub (Apr 16, 2021):

Thanks, wow some easter eggs!

Holding any Alt appears to force any open tab action (whether the plus button, picking a profile from dropdown, or ctrl+T) to open the tab as a pane...

@unphased commented on GitHub (Apr 16, 2021): Thanks, wow some easter eggs! Holding any Alt appears to force any open tab action (whether the plus button, picking a profile from dropdown, or ctrl+T) to open the tab as a pane...

claunia commented

2026-01-30 21:55:33 +00:00

@DHowett commented on GitHub (Apr 16, 2021):

Hmmm.. we were supposed to treat double-alt (assuming your keyboard sends left and right alt key codes!) as an override for single-alt. Let me check on that setting name, just to be sure.

@DHowett commented on GitHub (Apr 16, 2021): Hmmm.. we were supposed to treat double-alt (assuming your keyboard sends left and right alt key codes!) as an override for single-alt. Let me check on that setting name, just to be sure.

claunia commented

@DHowett commented on GitHub (Apr 16, 2021):

Sorry, it’s just "debugFeatures": true. 😄

@DHowett commented on GitHub (Apr 16, 2021): Sorry, it’s just `"debugFeatures": true`. :smile:

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

Awesome, this is working.

It appears to pump some output whenever a regular key is pressed, it sends some output when a modifier key like shift or ctrl is pressed, and also when they are released.

It looks like maybe the red stuff is what's received and the white stuff is what's sent out? Something like that, anyway. I got set up for screen capture, give me a sec and we'll take a look at what's going on with the different test cases.

@unphased commented on GitHub (Apr 16, 2021): Awesome, this is working. It appears to pump some output whenever a regular key is pressed, it sends some output when a modifier key like shift or ctrl is pressed, and also when they are released. It looks like maybe the red stuff is what's received and the white stuff is what's sent out? Something like that, anyway. I got set up for screen capture, give me a sec and we'll take a look at what's going on with the different test cases.

claunia commented

https://user-images.githubusercontent.com/1542910/114969866-1d2b6700-9e2e-11eb-978d-c6e1ddc66f5e.mp4

@unphased commented on GitHub (Apr 16, 2021):

Luckily this squeezes in under the 10MB github limit. Sorry for the rather small font, it's my preference but I realize it makes the debug pane pretty hard to read since it's got special chars in it. Do let me know if it's unreadable.

I may also be able to work this out on my own given this debug panel. I see a 1002 and a 1006 thing in the codes when nvim enables mouse...

I would also like to express my gratitude for your assistance in this.

@unphased commented on GitHub (Apr 16, 2021): https://user-images.githubusercontent.com/1542910/114969866-1d2b6700-9e2e-11eb-978d-c6e1ddc66f5e.mp4 Luckily this squeezes in under the 10MB github limit. Sorry for the rather small font, it's my preference but I realize it makes the debug pane pretty hard to read since it's got special chars in it. Do let me know if it's unreadable. I may also be able to work this out on my own given this debug panel. I see a 1002 and a 1006 thing in the codes when nvim enables mouse... I would also like to express my gratitude for your assistance in this.

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

Looks like nvim (which works to toggle it) spits out ␛[?1002h␛[?1006h␛[?25l␛[H␛[?25h when setting mouse=a and ␛[?1002l␛[?1006l␛[?25l␛[H␛[?25h when setting mouse=.

Vim is doing
␛[?1h␍␛[?1h␛[?25l␛[91C0,0-1␛[9CAll␛[H␛[?25h
and
␛[?1h␍␛[?1h␛[?25l␛[91C0,0-1␛[9CAll␛[H␛[?25h
respectively, which... look exactly the same.

echo -e "\e[?1000h" appears to produce ␛[?2004l␛[?2004h␛[?25l which makes very little sense to me also.

echo -e "\e[?1006h" produces ␛[?2004l␛[?2004h␛[?25l which is the same. So maybe bash is doing something weird here too.

?25h is Display Cursor
?1002h is to enable Cell Motion Mouse Tracking
?1006h is SGR Mouse Mode
the l counterparts are the opposite
H is just Home AFAICT
?2004 is bracketed paste mode. so I guess it just switches bracketed paste mode off while echoing and then switches it back on, (or toggling it twice for whatever reason) it's not really converting whatever into 2004. So my echoes aren't making it through. Maybe I shouldn't be running bash the way that I am.

I guess I'm at a loss if echo -e doesn't work from bash.

@unphased commented on GitHub (Apr 16, 2021): Looks like nvim (which works to toggle it) spits out `␛[?1002h␛[?1006h␛[?25l␛[H␛[?25h` when setting `mouse=a` and `␛[?1002l␛[?1006l␛[?25l␛[H␛[?25h` when setting `mouse=`. Vim is doing `␛[?1h␍␛[?1h␛[?25l␛[91C0,0-1␛[9CAll␛[H␛[?25h` and `␛[?1h␍␛[?1h␛[?25l␛[91C0,0-1␛[9CAll␛[H␛[?25h` respectively, which... look exactly the same. `echo -e "\e[?1000h"` appears to produce `␛[?2004l␛[?2004h␛[?25l` which makes very little sense to me also. `echo -e "\e[?1006h"` produces `␛[?2004l␛[?2004h␛[?25l` which is the same. So maybe bash is doing something weird here too. - `?25h` is Display Cursor - `?1002h` is to enable Cell Motion Mouse Tracking - `?1006h` is SGR Mouse Mode - the `l` counterparts are the opposite - `H` is just Home AFAICT - `?2004` is bracketed paste mode. so I guess it just switches bracketed paste mode off while echoing and then switches it back on, (or toggling it twice for whatever reason) it's not really converting whatever into 2004. So my echoes aren't making it through. Maybe I shouldn't be running bash the way that I am. I guess I'm at a loss if echo -e doesn't work from bash.

claunia commented

@tig commented on GitHub (Apr 16, 2021):

Can we get someone on the Windows Terminal team to explain what needs to happen for Terminal.Gui apps to work with Windows Terminal now that it (apparently) has mouse support?

If I understand all this correctly (please correct me if I'm wrong):

The root cause was in OpenSSH. This has been fixed in a future OpenSSH version.
Once that OpenSSH version is on a Windows 10 PC, the mouse on Windows Terminal 1.8 and above will just work with Terminal.Gui apps

If this is correct, is there a way I can get an OpenSSH build installed so I can test it now?

I think Terminal.Gui working in Windows Terminal as well as it does in cmd.exe or ConEmu should be an exit criterion for declaring WT supports mouse. Can we get a commitment from the Windows Terminal team that they will add Terminal.Gui to their validation for mouse support?

@tig commented on GitHub (Apr 16, 2021): Can we get someone on the Windows Terminal team to explain what needs to happen for `Terminal.Gui` apps to work with Windows Terminal now that it (apparently) has mouse support? If I understand all this correctly (please correct me if I'm wrong): - The root cause was in OpenSSH. This has been fixed in a future OpenSSH version. - Once that OpenSSH version is on a Windows 10 PC, the mouse on Windows Terminal 1.8 and above will just work with `Terminal.Gui` apps If this is correct, is there a way I can get an OpenSSH build installed so I can test it now? I think `Terminal.Gui` working in Windows Terminal as well as it does in cmd.exe or ConEmu should be an exit criterion for declaring WT supports mouse. Can we get a commitment from the Windows Terminal team that they will add `Terminal.Gui` to their validation for mouse support?

claunia commented

@zadjii-msft commented on GitHub (Apr 16, 2021):

If Terminal.Gui is using VT-style mouse mode on Windows 10, then mouse input via Windows Terminal will just automatically work for them locally, like it does for WSL.
If they're using Win32-style mouse mode, then mouse input in Windows Terminal won't work until this issue is resolved.
If you're connected to something via Win32-OpenSSH, v7.* (the ssh.exe that ships with Windows), then you're always gonna have a bad time. The advice is to update to 8.*

I believe that's the current lay of the land. I don't know which style mouse input they're using, but I'd bet it's the Win32 style.

@zadjii-msft commented on GitHub (Apr 16, 2021): * If Terminal.Gui is using VT-style mouse mode on Windows 10, then mouse input via Windows Terminal will just automatically work for them locally, like it does for WSL. * If they're using Win32-style mouse mode, then mouse input in Windows Terminal won't work until _this_ issue is resolved. * If you're connected to something via Win32-OpenSSH, v7.\* (the `ssh.exe` that ships with Windows), then you're always gonna have a bad time. The advice is to update to 8.\* I believe that's the current lay of the land. I don't know which style mouse input they're using, but I'd bet it's the Win32 style.

claunia commented

28580de3c5/Terminal.Gui/ConsoleDrivers/WindowsDriver.cs (L269)

@tig commented on GitHub (Apr 16, 2021):

If Terminal.Gui is using VT-style mouse mode on Windows 10, then mouse input via Windows Terminal will just automatically work for them locally, like it does for WSL.

If they're using Win32-style mouse mode, then mouse input in Windows Terminal won't work until this issue is resolved.

If you're connected to something via Win32-OpenSSH, v7.* (the ssh.exe that ships with Windows), then you're always gonna have a bad time. The advice is to update to 8.*

I believe that's the current lay of the land. I don't know which style mouse input they're using, but I'd bet it's the Win32 style.

Good info. Here's our tracking issue: https://github.com/migueldeicaza/gui.cs/issues/332

Here's the code for Mouse support in our Windows driver:

Pretty sure that means we're using Windows style.

Our Linux driver is here:

https://github.com/migueldeicaza/gui.cs/blob/master/Terminal.Gui/ConsoleDrivers/CursesDriver/CursesDriver.cs

I don't have time right now to understand what it is using (is Curses == VT-style???).

FWIW, running our UICatalog app in WT 1.8 with WSL (Debian 10) results in some mouse stuff working (tracking but no clicks).

@tig commented on GitHub (Apr 16, 2021): > * If Terminal.Gui is using VT-style mouse mode on Windows 10, then mouse input via Windows Terminal will just automatically work for them locally, like it does for WSL. > * If they're using Win32-style mouse mode, then mouse input in Windows Terminal won't work until _this_ issue is resolved. > * If you're connected to something via Win32-OpenSSH, v7.* (the `ssh.exe` that ships with Windows), then you're always gonna have a bad time. The advice is to update to 8.* > > I believe that's the current lay of the land. I don't know which style mouse input they're using, but I'd bet it's the Win32 style. Good info. Here's our tracking issue: https://github.com/migueldeicaza/gui.cs/issues/332 Here's the code for Mouse support in our Windows driver: https://github.com/migueldeicaza/gui.cs/blob/28580de3c57fe4fc03ddef157f4c4cc879a5bda0/Terminal.Gui/ConsoleDrivers/WindowsDriver.cs#L269 Pretty sure that means we're using Windows style. Our Linux driver is here: https://github.com/migueldeicaza/gui.cs/blob/master/Terminal.Gui/ConsoleDrivers/CursesDriver/CursesDriver.cs I don't have time right now to understand what it is using (is Curses == VT-style???). FWIW, running our `UICatalog` app in WT 1.8 with WSL (Debian 10) results in some mouse stuff working (tracking but no clicks).

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

@DHowett Could I get your take on my reporting above, it seems like neovim is able to set the mouse mode in a way that is satisfactory to Terminal but MSYS2's vim, bash, and ssh all don't. I don't understand the distinction of what win32 style mouse input is supposed to be. Is that the reason for why neovim works? Is it this code?

Maybe my MSYS2 tool experiments are just misguided and I need to install OpenSSH 8 for windows. I am having trouble working out how to install 8.1.0.0 and it's also kind of problematic that it's a 2 year old build.

@unphased commented on GitHub (Apr 16, 2021): @DHowett Could I get your take on my reporting above, it seems like neovim is able to set the mouse mode in a way that is satisfactory to Terminal but MSYS2's vim, bash, and ssh all don't. I don't understand the distinction of what win32 style mouse input is supposed to be. Is that the reason for why neovim works? Is it [this code](https://github.com/neovim/neovim/blob/8e496b9dfd5b644f06536afea63e3088b9d83cf8/src/nvim/tui/tui.c#L1033)? Maybe my MSYS2 tool experiments are just misguided and I need to install OpenSSH 8 for windows. I am having trouble working out how to install 8.1.0.0 and it's also kind of problematic that it's a 2 year old build.

claunia commented

@DHowett commented on GitHub (Apr 16, 2021):

@unphased so, VT mouse mode is the more "standard" control sequence-based encoding for mouse events, where mouse input comes in as a coded text stream; projects written for platforms other than Windows tend to use it. It's the one controlled by DECSET 1000, 1002, 1006, and friends. Works great over SSH (when their Win32 compatibility code doesn't get in the way).

Win32 mouse mode is an artifact of the Windows console ecosystem, where mouse events come in as data structures through ReadConsoleInput[AW]. (SSH can't even handle these, so it actually just totally drops all mouse input on the floor, even when Terminal tries.)

This specific issue tracks converting standard VT mouse input into Win32 mouse mode so that Terminal can continue to speak standards-language and Windows applications that expect Windows mouse input (FAR manager comes to mind) can get it.

What you're seeing is a failure of MSYS2 to send us a request for mouse mode. I suspect I know why this is happening. . . and because of that I'd like to direct discussion of this particular bug over to #6859

In short: msys/the cygwin runtime (they're one and the same) is telling us to enable mouse mode after it tells us "i cannot handle VT input". This is incomprehensible to Terminal.

@DHowett commented on GitHub (Apr 16, 2021): @unphased so, VT mouse mode is the more "standard" control sequence-based encoding for mouse events, where mouse input comes in as a coded text stream; projects written for platforms other than Windows tend to use it. It's the one controlled by DECSET 1000, 1002, 1006, and friends. Works great over SSH (when their Win32 compatibility code doesn't get in the way). Win32 mouse mode is an artifact of the Windows console ecosystem, where mouse events come in as data structures through `ReadConsoleInput[AW]`. (SSH can't even handle these, so it actually just totally drops all mouse input on the floor, even when Terminal tries.) This specific issue tracks converting _standard VT mouse input_ into _Win32 mouse mode_ so that Terminal can continue to speak standards-language and Windows applications that expect Windows mouse input (FAR manager comes to mind) can get it. What you're seeing is a failure of MSYS2 to send us a request for mouse mode. I suspect I know why this is happening. . . and because of that I'd like to direct discussion of this particular bug over to #6859 _In short:_ msys/the cygwin runtime (they're one and the same) is telling us to enable mouse mode after it tells us "i cannot handle VT input". This is incomprehensible to Terminal.

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

@DHowett Thank you for the update. Does that mean that my wild guess is sort of close? E.g. that there are some deeper issues with MSYS2's bash/ssh that are preventing things from working properly (even though its ssh is an improvement over windows OpenSSH 7.x) and that i will need a windows build of OpenSSH 8.x to use and it should be able to do a good job of handling escape codes including mouse codes? And that this is all VT mouse stuff. I'm mainly interested in the use of Linux/UNIX systems from windows, so that means WSL/WSL2 (which has been fine for a while) and SSH to another host.

@unphased commented on GitHub (Apr 16, 2021): @DHowett Thank you for the update. Does that mean that my wild guess is sort of close? E.g. that there are some deeper issues with MSYS2's bash/ssh that are preventing things from working properly (even though its ssh is an improvement over windows OpenSSH 7.x) and that i will need a windows build of OpenSSH 8.x to use and it should be able to do a good job of handling escape codes including mouse codes? And that this is all VT mouse stuff. I'm mainly interested in the use of Linux/UNIX systems from windows, so that means WSL/WSL2 (which has been fine for a while) and SSH to another host.

claunia commented

@DHowett commented on GitHub (Apr 16, 2021):

Indeed! I'm not sure the best way to install their latest release, sorry. I'm a bit out of the loop.

WSL + SSH should work perfectly, however. 😄

@DHowett commented on GitHub (Apr 16, 2021): Indeed! I'm not sure the best way to install their latest release, sorry. I'm a bit out of the loop. WSL + SSH should work perfectly, however. :smile:

claunia commented

@unphased commented on GitHub (Apr 16, 2021):

WSL + SSH

That's not a bad idea. But... I'm actually going the other way around with a Linux host and Win10 as a KVM guest using VFIO for PCIe peripherals (including GPU) these days. Trying to set up a holy grail situation where I can pass the GPU in when booting up windows virtually, and access the underlying host via SSH for terminal based development, which I've been doing for 10 years. This way the host can build software while the Windows client is fully accelerated, all on one local machine.

I don't think it will be very doable to run HyperV from inside a kvm guest. It would be interesting. It may work. But, I'm not really interested.

@unphased commented on GitHub (Apr 16, 2021): > WSL + SSH That's not a bad idea. But... I'm actually going the other way around with a Linux host and Win10 as a KVM guest using VFIO for PCIe peripherals (including GPU) these days. Trying to set up a holy grail situation where I can pass the GPU in when booting up windows virtually, and access the underlying host via SSH for terminal based development, which I've been doing for 10 years. This way the host can build software while the Windows client is fully accelerated, all on one local machine. I don't think it will be very doable to run HyperV from inside a kvm guest. It would be interesting. It may work. But, I'm not really interested.

claunia commented

https://user-images.githubusercontent.com/20713561/115096027-cdc76280-9f23-11eb-8884-fcf0caa4c3b0.mp4

@magiblot commented on GitHub (Apr 17, 2021):

This specific issue tracks converting standard VT mouse input into Win32 mouse mode so that Terminal can continue to speak standards-language and Windows applications that expect Windows mouse input (FAR manager comes to mind) can get it.

Just like you say, apps using the Win32 API do not receive mouse events in Windows Terminal. However, if I follow these steps:

Open Cmd/Powershell/Git Bash in a new tab in Windows Terminal.
Run wsl.
In the WSL prompt, run printf "\x1B[?1002h\x1B[?1006h"
Exit WSL.
Run a Win32 console application: mouse events work! How so?

The following sample program and video demonstrate this behaviour:

mouseon.cpp

#define NOMINMAX
#include <windows.h>
#include <stdio.h>

void input_loop(HANDLE in)
{
    INPUT_RECORD irBuffer;
    DWORD eventsRead;
    BOOL ret;
    while ((ret = ReadConsoleInputW(in, &irBuffer, 1, &eventsRead)) != FALSE)
    {
        if (eventsRead != 0)
        {
            if (irBuffer.EventType == KEY_EVENT)
            {
                if ((irBuffer.Event.KeyEvent.bKeyDown || irBuffer.Event.KeyEvent.wVirtualKeyCode == VK_MENU) && irBuffer.Event.KeyEvent.uChar.UnicodeChar)
                {
                    if (irBuffer.Event.KeyEvent.uChar.AsciiChar == '\x03' && (irBuffer.Event.KeyEvent.dwControlKeyState & (LEFT_CTRL_PRESSED | RIGHT_CTRL_PRESSED)))
                    {
                        // CTRL+C
                        break;
                    }

                    static unsigned short surrogate = 0;
                    unsigned char ascii = irBuffer.Event.KeyEvent.uChar.AsciiChar;
                    unsigned short unicode[2] = {irBuffer.Event.KeyEvent.uChar.UnicodeChar, 0};
                    if (0xD800 <= *unicode && *unicode <= 0xDBFF)
                    {
                        printf("High surrogate: %u\n", *unicode);
                        surrogate = (unsigned short) *unicode;
                    }
                    else
                    {
                        if (surrogate)
                        {
                            if (0xDC00 <= *unicode && *unicode <= 0xDFFF)
                            {
                                printf("Low surrogate: %u\n", *unicode);
                                unicode[1] = *unicode;
                                unicode[0] = surrogate;
                            }
                            surrogate = 0;
                        }
                        unsigned short keycode = irBuffer.Event.KeyEvent.wVirtualKeyCode;
                        char utf8[5];
                        int len = WideCharToMultiByte(
                            65001,
                            0,
                            (wchar_t*) &unicode,
                            2,
                            utf8,
                            4,
                            0, 0);
                        utf8[len] = '\0';
                        printf("ASCII: %u, Unicode: %u, KeyCode: %u, UTF-8: '%s'\n", ascii, *unicode, keycode, utf8);
                    }
                }
            }
            else if (irBuffer.EventType == MOUSE_EVENT)
            {
                int x = irBuffer.Event.MouseEvent.dwMousePosition.X;
                int y = irBuffer.Event.MouseEvent.dwMousePosition.Y;
                int but = irBuffer.Event.MouseEvent.dwButtonState;
                int st = irBuffer.Event.MouseEvent.dwControlKeyState;
                int ev = irBuffer.Event.MouseEvent.dwEventFlags;
                printf("Mouse(%d, %d), Buttons: 0x%X, CtrlKey: 0x%X, EventFlags: 0x%X\n", x, y, but, st, ev);
            }
        }
        WaitForSingleObject(in, 50);
    }
    if (ret == FALSE)
        printf("ReadConsoleInputW failed: %u\n", GetLastError());
}

int main()
{
    HANDLE in = GetStdHandle(STD_INPUT_HANDLE);
    DWORD oldConsoleMode = 0;
    GetConsoleMode(in, &oldConsoleMode);
    printf("Console Mode: 0x%X\n", oldConsoleMode);
    DWORD consoleMode = oldConsoleMode;
    consoleMode &= ~ENABLE_PROCESSED_INPUT;
    consoleMode |= ENABLE_EXTENDED_FLAGS;
    consoleMode &= ~ENABLE_QUICK_EDIT_MODE;
    consoleMode |= ENABLE_MOUSE_INPUT;
    SetConsoleMode(in, consoleMode);
    printf("Corrected Console Mode: 0x%X\n", consoleMode);

    input_loop(in);

    SetConsoleMode(in, oldConsoleMode);
    printf("Restoring Console Mode: 0x%X\n", oldConsoleMode);
    return 0;
}

Cheers.

@magiblot commented on GitHub (Apr 17, 2021): > This specific issue tracks converting standard VT mouse input into Win32 mouse mode so that Terminal can continue to speak standards-language and Windows applications that expect Windows mouse input (FAR manager comes to mind) can get it. Just like you say, apps using the Win32 API do not receive mouse events in Windows Terminal. However, if I follow these steps: 1. Open Cmd/Powershell/Git Bash in a new tab in Windows Terminal. 2. Run `wsl`. 3. In the WSL prompt, run `printf "\x1B[?1002h\x1B[?1006h"` 4. Exit WSL. 5. Run a Win32 console application: mouse events work! How so? The following sample program and video demonstrate this behaviour: <details> <summary>mouseon.cpp</summary> ```c++ #define NOMINMAX #include <windows.h> #include <stdio.h> void input_loop(HANDLE in) { INPUT_RECORD irBuffer; DWORD eventsRead; BOOL ret; while ((ret = ReadConsoleInputW(in, &irBuffer, 1, &eventsRead)) != FALSE) { if (eventsRead != 0) { if (irBuffer.EventType == KEY_EVENT) { if ((irBuffer.Event.KeyEvent.bKeyDown || irBuffer.Event.KeyEvent.wVirtualKeyCode == VK_MENU) && irBuffer.Event.KeyEvent.uChar.UnicodeChar) { if (irBuffer.Event.KeyEvent.uChar.AsciiChar == '\x03' && (irBuffer.Event.KeyEvent.dwControlKeyState & (LEFT_CTRL_PRESSED | RIGHT_CTRL_PRESSED))) { // CTRL+C break; } static unsigned short surrogate = 0; unsigned char ascii = irBuffer.Event.KeyEvent.uChar.AsciiChar; unsigned short unicode[2] = {irBuffer.Event.KeyEvent.uChar.UnicodeChar, 0}; if (0xD800 <= *unicode && *unicode <= 0xDBFF) { printf("High surrogate: %u\n", *unicode); surrogate = (unsigned short) *unicode; } else { if (surrogate) { if (0xDC00 <= *unicode && *unicode <= 0xDFFF) { printf("Low surrogate: %u\n", *unicode); unicode[1] = *unicode; unicode[0] = surrogate; } surrogate = 0; } unsigned short keycode = irBuffer.Event.KeyEvent.wVirtualKeyCode; char utf8[5]; int len = WideCharToMultiByte( 65001, 0, (wchar_t*) &unicode, 2, utf8, 4, 0, 0); utf8[len] = '\0'; printf("ASCII: %u, Unicode: %u, KeyCode: %u, UTF-8: '%s'\n", ascii, *unicode, keycode, utf8); } } } else if (irBuffer.EventType == MOUSE_EVENT) { int x = irBuffer.Event.MouseEvent.dwMousePosition.X; int y = irBuffer.Event.MouseEvent.dwMousePosition.Y; int but = irBuffer.Event.MouseEvent.dwButtonState; int st = irBuffer.Event.MouseEvent.dwControlKeyState; int ev = irBuffer.Event.MouseEvent.dwEventFlags; printf("Mouse(%d, %d), Buttons: 0x%X, CtrlKey: 0x%X, EventFlags: 0x%X\n", x, y, but, st, ev); } } WaitForSingleObject(in, 50); } if (ret == FALSE) printf("ReadConsoleInputW failed: %u\n", GetLastError()); } int main() { HANDLE in = GetStdHandle(STD_INPUT_HANDLE); DWORD oldConsoleMode = 0; GetConsoleMode(in, &oldConsoleMode); printf("Console Mode: 0x%X\n", oldConsoleMode); DWORD consoleMode = oldConsoleMode; consoleMode &= ~ENABLE_PROCESSED_INPUT; consoleMode |= ENABLE_EXTENDED_FLAGS; consoleMode &= ~ENABLE_QUICK_EDIT_MODE; consoleMode |= ENABLE_MOUSE_INPUT; SetConsoleMode(in, consoleMode); printf("Corrected Console Mode: 0x%X\n", consoleMode); input_loop(in); SetConsoleMode(in, oldConsoleMode); printf("Restoring Console Mode: 0x%X\n", oldConsoleMode); return 0; } ``` </details> https://user-images.githubusercontent.com/20713561/115096027-cdc76280-9f23-11eb-8884-fcf0caa4c3b0.mp4 Cheers.

claunia commented

@DHowett commented on GitHub (Apr 17, 2021):

@magiblot we have the translator (thanks to @carlos-zamora!) but we do not have the infrastructure that converts a Win32 call to SetConsoleMode on the input handle into a DECSET 1000/1006. 😄

I’ve asked @PankajBhojwani to look into it.

@DHowett commented on GitHub (Apr 17, 2021): @magiblot we have the translator (thanks to @carlos-zamora!) but we do not have the infrastructure that converts a Win32 call to `SetConsoleMode` on the input handle into a DECSET 1000/1006. :smile: I’ve asked @PankajBhojwani to look into it.

claunia commented

@magiblot commented on GitHub (Apr 17, 2021):

Thanks Dustin. Then this is almost fixed, isn't it?

@magiblot commented on GitHub (Apr 17, 2021): Thanks Dustin. Then this is almost fixed, isn't it?

claunia commented

@unphased commented on GitHub (Apr 18, 2021):

@DHowett Thanks again for your help. I was able to get the OpenSSH 8.1 installed via this answer and I have mouse events working in Windows Terminal. Beautiful.

@unphased commented on GitHub (Apr 18, 2021): @DHowett Thanks again for your help. I was able to get the OpenSSH 8.1 installed via [this answer](https://superuser.com/a/1609071/98199) and I have mouse events working in Windows Terminal. Beautiful.

claunia commented

@tig commented on GitHub (Apr 18, 2021):

I just did the following

Installed latest OpenSSH:

@DHowett Thanks again for your help. I was able to get the OpenSSH 8.1 installed via this answer and I have mouse events working in Windows Terminal. Beautiful.

Open Cmd/Powershell/Git Bash in a new tab in Windows Terminal.

Run wsl.

In the WSL prompt, run printf "\x1B[?1002h\x1B[?1006h"

Exit WSL.

Run a Win32 console application: mouse events work! How so?

Ran Terminal.Gui's sample app in Windows Terminal 1.8:

The mouse partially works WHICH IS A HUGE VICTORY!

However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example.

@unphased did you see all mouse events when you tried this???

@tig commented on GitHub (Apr 18, 2021): I just did the following Installed latest OpenSSH: > @DHowett Thanks again for your help. I was able to get the OpenSSH 8.1 installed via [this answer](https://superuser.com/a/1609071/98199) and I have mouse events working in Windows Terminal. Beautiful. ![image](https://user-images.githubusercontent.com/585482/115153301-08b3be00-a02a-11eb-8304-166450e4b1e2.png) > * Open Cmd/Powershell/Git Bash in a new tab in Windows Terminal. > * Run `wsl`. > * In the WSL prompt, run `printf "\x1B[?1002h\x1B[?1006h"` > * Exit WSL. > * Run a Win32 console application: mouse events work! How so? Ran `Terminal.Gui`'s sample app in Windows Terminal 1.8: ![image](https://user-images.githubusercontent.com/585482/115153316-241ec900-a02a-11eb-9078-5c07b41589f0.png) The mouse partially works WHICH IS A HUGE VICTORY! However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example. @unphased did you see all mouse events when you tried this???

claunia commented

@magiblot commented on GitHub (Apr 18, 2021):

However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example.

Mouse move events might work if you do printf "\x1B[?1003h\x1B[?1006h" (with 1003 instead of 1002).

@magiblot commented on GitHub (Apr 18, 2021): > However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example. Mouse move events might work if you do `printf "\x1B[?1003h\x1B[?1006h"` (with `1003` instead of `1002`).

claunia commented

@tig commented on GitHub (Apr 18, 2021):

However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example.

Mouse move events might work if you do printf "\x1B[?1003h\x1B[?1006h" (with 1003 instead of 1002).

That did not appear to work.

@tig commented on GitHub (Apr 18, 2021): > > However, we're not receiving all mouse events. Double click, mouse move, and mouse wheel are not working, for example. > > Mouse move events might work if you do `printf "\x1B[?1003h\x1B[?1006h"` (with `1003` instead of `1002`). That did not appear to work.

claunia commented

@unphased commented on GitHub (Apr 18, 2021):

I did not specifically test doubleclick since I rarely use that in my tmux/vim workflows. But move and wheel definitely worked.

@unphased commented on GitHub (Apr 18, 2021): I did not specifically test doubleclick since I rarely use that in my tmux/vim workflows. But move and wheel definitely worked.

claunia commented

@DHowett commented on GitHub (Apr 19, 2021):

@tig just so you know, we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. 😄

We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing.

@DHowett commented on GitHub (Apr 19, 2021): @tig just so you know, _we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed_, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. :smile: We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing.

claunia commented

@tig commented on GitHub (Apr 19, 2021):

@tig just so you know, we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. 😄

We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing.

Right on! Hugs.

@tig commented on GitHub (Apr 19, 2021): > @tig just so you know, _we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed_, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. 😄 > > We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing. Right on! Hugs.

claunia commented

@nkrepo commented on GitHub (Apr 20, 2021):

we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. 😄

We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing.

@DHowett do you an ETA when Win32 mouse for pseudoconsole will land?

@nkrepo commented on GitHub (Apr 20, 2021): > _we will not officially support Win32 mouse input through the pseudoconsole until this issue is closed_, so I cannot countenance shipping a solution that depends on enabling VT mouse input directly. 😄 > > We'll make sure that all sorts of mouse events work (hover, wheel, click w/ any combination of buttons) before closing. @DHowett do you an ETA when Win32 mouse for pseudoconsole will land?

claunia commented

@DHowett commented on GitHub (Apr 20, 2021):

@nkrepo before Terminal 2.0, for sure.

@DHowett commented on GitHub (Apr 20, 2021): @nkrepo before Terminal 2.0, for sure.

claunia commented

@Luk164 commented on GitHub (May 2, 2021):

I tried installing OpenSSH 8 and use it together with WT but mouse events did not work. WSL worked and when I used SSH within WSL it worked too. Did I mess up somewhere?

@Luk164 commented on GitHub (May 2, 2021): I tried installing OpenSSH 8 and use it together with WT but mouse events did not work. WSL worked and when I used SSH within WSL it worked too. Did I mess up somewhere?

claunia commented

2026-01-30 21:55:40 +00:00

@zadjii-msft commented on GitHub (May 27, 2021):

Wait uh, did #9970 close this? @DHowett

@zadjii-msft commented on GitHub (May 27, 2021): Wait uh, did #9970 close this? @DHowett

claunia commented

@billybraga commented on GitHub (May 27, 2021):

With Microsoft Terminal Preview 1.9.14450.0 and using set mouse=a in vim, scrolling works for me!!!

@billybraga commented on GitHub (May 27, 2021): With Microsoft Terminal Preview 1.9.14450.0 and using `set mouse=a` in vim, scrolling works for me!!!

claunia commented

2026-01-30 21:55:40 +00:00

@DHowett commented on GitHub (May 27, 2021):

Hey, it sure should have!

@DHowett commented on GitHub (May 27, 2021): Hey, it sure should have!

claunia commented

2026-01-30 21:55:40 +00:00

@DHowett commented on GitHub (May 27, 2021):

For everyone following along in the audience: This shipped with ConPTY as of Terminal 1.9; eventually the change will flow back out to Windows as well.

@DHowett commented on GitHub (May 27, 2021): For everyone following along in the audience: This shipped with ConPTY as of Terminal 1.9; eventually the change will flow back out to Windows as well.

claunia commented

@tig commented on GitHub (May 27, 2021):

Woot! Woot! Woot.

I've just closed https://github.com/migueldeicaza/gui.cs/issues/332

I thank you. And all Terminal.Gui users thank you.

@tig commented on GitHub (May 27, 2021): Woot! Woot! Woot. I've just closed https://github.com/migueldeicaza/gui.cs/issues/332 I thank you. And all Terminal.Gui users thank you.

claunia commented

@ozgb commented on GitHub (May 27, 2021):

Thank you devs! 🎉❤️ Been following this one for a while!

@ozgb commented on GitHub (May 27, 2021): Thank you devs! 🎉❤️ Been following this one for a while!

claunia commented

@silverqx commented on GitHub (Oct 11, 2021):

With Microsoft Terminal Preview 1.9.14450.0 and using set mouse=a in vim, scrolling works for me!!!

Does it really work for you? Because it does not for me, I'm talking about pure vim on windows in windows terminal.

WinTerm - 1.11.2731
Vim - 8.2.3487

It only works if I ssh to my Gentoo virtual machine and run vim there (from the WindowsTerminal or from the cmd terminal) and it also works when I start vim from MSYS2 mingw64.
Is good to tell that scrolling works in the Midnight Commander ( mc.exe executed in WT ).

Left-click works for me in all the above-described environments.

I have tried different settings, --clean param, and also tried to disable QuickEdit Mode.
Scrolling does not work also in the cmd and PowerShell terminals.

@silverqx commented on GitHub (Oct 11, 2021): > With Microsoft Terminal Preview 1.9.14450.0 and using `set mouse=a` in vim, scrolling works for me!!! Does it really work for you? Because it does not for me, I'm talking about pure vim on windows in windows terminal. WinTerm - 1.11.2731 Vim - 8.2.3487 It only works if I ssh to my Gentoo virtual machine and run vim there (from the WindowsTerminal or from the cmd terminal) and it also works when I start vim from MSYS2 mingw64. Is good to tell that scrolling works in the Midnight Commander ( mc.exe executed in WT ). Left-click works for me in all the above-described environments. I have tried different settings, --clean param, and also tried to disable QuickEdit Mode. Scrolling does not work also in the cmd and PowerShell terminals.

claunia commented

@rbreaves commented on GitHub (Nov 18, 2021):

@DHowett @DHowett-MSFT I have noticed that the current release build of Windows 10 does not appear to have mouse support when going through VSCode's integrated console - however Windows 11 and VSCode does have mouse support in the integrated Powershell console (to ssh sessions).

Is this is an oversight and will it be remedied in a future update? Also the VSCode team says the issue is with ConPTY, not VSCode.

@rbreaves commented on GitHub (Nov 18, 2021): @DHowett @DHowett-MSFT I have noticed that the current release build of Windows 10 does not appear to have mouse support when going through VSCode's integrated console - however Windows 11 and VSCode does have mouse support in the integrated Powershell console (to ssh sessions). Is this is an oversight and will it be remedied in a future update? Also the VSCode team says the issue is with ConPTY, not VSCode.

claunia commented

@DHowett commented on GitHub (Nov 18, 2021):

@rbreaves Unfortunately, they're right -- the issue is in ConPTY. Also unfortunate is that we don't get any say in what features get backported to Windows 10 ☹️.

Effectively, Windows development has all moved on to Windows 11. Only specific features, with leadership approval, get cherry-picked into the stable Windows 10 branches. The successive updates to Windows 10 20H1 (20H2, 21H1, 21H2) are all based on the same original code plus some "leadership approved" features backported.

That's why we're working so hard to get conhost (and therefore conpty) decoupled from the operating system: so that we can give folks like you updates in a more timely fashion.

@DHowett commented on GitHub (Nov 18, 2021): @rbreaves Unfortunately, they're right -- the issue is in ConPTY. Also unfortunate is that we don't get any say in what features get backported to Windows 10 ☹️. Effectively, Windows development has all moved on to Windows 11. Only specific features, with leadership approval, get cherry-picked into the stable Windows 10 branches. The successive updates to Windows 10 20H1 (20H2, 21H1, 21H2) are all based on the same original code plus some "leadership approved" features backported. That's why we're working so hard to get conhost (and therefore conpty) decoupled from the operating system: so that we can give folks like you updates in a more timely fashion.

claunia commented

@sdegutis commented on GitHub (Jan 22, 2022):

Is this by any chance why mouse support in tig (with set mouse = true in ~/.tigrc) does not work inside git-bash in Windows Terminal, but does work inside Ubuntu in Windows Terminal? They're both Windows Terminal which is why I thought both should work identically?

@sdegutis commented on GitHub (Jan 22, 2022): Is this by any chance why mouse support in `tig` (with `set mouse = true` in `~/.tigrc`) does not work inside git-bash in Windows Terminal, but *does* work inside Ubuntu in Windows Terminal? They're both Windows Terminal which is why I thought both should work identically?

claunia commented

https://gist.github.com/rbreaves/eb7c989ecf71440e31d1f159d2a4619d

@rbreaves commented on GitHub (Jan 22, 2022):

Oddly enough I’ve mostly stopped using the built in Terminal w/ vscode. I now toggle Windows Terminal as though it’s a quake terminal which works fine either way. I didn’t do this because of the lack of proper conpty support in vscode though w/ win10. I moved on because I do a fake blur w/ glassit & just wanted more space for my code editor.

I still think it’s important for them to decouple conpty - clearly leadership doesn’t understand its importance to developers. Guessing its fix looks no better than a half a dozen others they’d reject & unless you’re a dev then a good terminal experience is just “nice to have” & not a must.

@rbreaves commented on GitHub (Jan 22, 2022): Oddly enough I’ve mostly stopped using the built in Terminal w/ vscode. I now toggle Windows Terminal as though it’s a quake terminal which works fine either way. I didn’t do this because of the lack of proper conpty support in vscode though w/ win10. I moved on because I do a fake blur w/ glassit & just wanted more space for my code editor. I still think it’s important for them to decouple conpty - clearly leadership doesn’t understand its importance to developers. Guessing its fix looks no better than a half a dozen others they’d reject & unless you’re a dev then a good terminal experience is just “nice to have” & not a must. https://gist.github.com/rbreaves/eb7c989ecf71440e31d1f159d2a4619d

claunia commented

@cbartondock commented on GitHub (May 15, 2022):

:set mouse=a still not working for me in Powershell + VIM. No scrolling.

@cbartondock commented on GitHub (May 15, 2022): `:set mouse=a` still not working for me in Powershell + VIM. No scrolling.

claunia commented

@rbreaves commented on GitHub (May 15, 2022):

Why would it? Vim was written to work w/ posix compliant shells.. aka sh, bash, zsh. Etc.

@rbreaves commented on GitHub (May 15, 2022): Why would it? Vim was written to work w/ posix compliant shells.. aka sh, bash, zsh. Etc.

claunia commented

@zadjii-msft commented on GitHub (May 16, 2022):

@rbreaves That's just... not accurate at all. The shell should have nothing to do with how vim handles mouse mode. Mouse mode is a terminal feature, not a shell one.

@cbartondock would you mind filing a separate issue so we can follow up with you and get to the root cause of your issue? Mouse mode should generally work for both the console and the Terminal now. There are a few bugs on the backlog IIRC, but filing a separate issue would be the easiest way for us to get to the root cause here. (without pinging the other 50 people on this thread 😝)

@zadjii-msft commented on GitHub (May 16, 2022): @rbreaves That's just... not accurate at all. The shell should have nothing to do with how vim handles mouse mode. Mouse mode is a _terminal_ feature, not a shell one. @cbartondock would you mind filing a separate issue so we can follow up with you and get to the root cause of your issue? Mouse mode should generally work for both the console and the Terminal now. There are a few bugs on the backlog IIRC, but filing a separate issue would be the easiest way for us to get to the root cause here. (without pinging the other 50 people on this thread 😝)

claunia commented