alacritty: Mouse interactions do not appear to be working properly on windows

Original issue by @dparnell

Which operating system does the issue occur on?

Windows 10 client connecting to a Linux 16.04 machine via ssh

Steps to reproduce:

  1. Make sure that dialog is installed
  2. Execute dialog --yesno Testing 10 30
  3. Attempt to use the mouse to click on either the Yes or No button. Nothing happens

Expected bahavior:

Clicking on either of the buttons should cause the dialog process to exit

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 27
  • Comments: 78 (18 by maintainers)

Commits related to this issue

Most upvoted comments

@abdenourgnx Sure!

  1. Go to https://github.com/wez/wezterm/tree/main/assets/windows/conhost and download OpenConsole.exe and conpty.dll
  2. Put these files into your alacritty program directory (e.g. c:\Program Files\Alacritty\ )

That’s all! Alacritty will find these files and use them. (Unless you explicity disabled the conpty feature by setting winpty_backend to True)

Exactly. Copy openconsole.exe it to C:\Windows\System32 and rename it to conhost.exe (probably should save the original conhost though, just to be safe).

Hi, i want to confirm this is the entire process necessary to get this to work? or are there other steps? Currently, i start alacritty, then run wsl, then run tmux. is the above step all i would need to get the scroll wheel, etc working?

  1. Close all running cmd program, like cmd or running alacritty.
  2. Rename your original conhost.exe to other names like conhost.exe_bak in C:\Windows\System32\
  3. Go to Windows Terminal path C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_<VERSION information>\OpenConsole.exe
    e.g.:C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe\OpenConsole.exe
  4. Copy and rename OpenConsole.exe to C:\Windows\System32\conhost.exe
  5. Reopen your alacrity and open wsl then tmux, you can enjoy~ BTW, please make sure you keep winpty_backend: false in alacrity config.

And you can check this by using windows task manager image

A much less hacky solution is to build my branch https://github.com/fredizzimo/alacritty/tree/add_openconsole_support, then build the Windows terminal, following these instructions https://github.com/microsoft/terminal#developer-guidance.

After that you can copy conpty.dll and openconsole.exe from the windows terminal binaries into the same directory as your custom version of Alacritty. They will then be automatically loaded when you launch Alacritty and the mouse and other things should work as they should. And if you for some reason don’t want to load them anymore, you can just delete them, and Alacritty will use the default Windows implementation like before.

I made a pull request a long time ago https://github.com/alacritty/alacritty/pull/4501, but the maintainers of Alacritty are totally unwilling to accept the changes. Somehow they have problems accepting a library provided by Microsoft, which is used in virtually all other Windows terminal emulators, just because Windows includes an older version of it by default.

BTW, you might want to merge a newer version of Alacritty on top of my branch, since I haven’t updated it for a while. And I doubt that I will update it in the future, unless the the project maintainers are willing to accept it or at least review it, since I have personally moved on to Windows 11, where everything seems to be fixed. But I’m not fully sure it is, since I haven’t had Windows 11 for too long, and I also have mostly switched over to use the Neovim built in terminal through the Neovide GUI, so I don’t use Alacritty that much anymore.

@Neur0toxine that worked, thanks a lot! 😃 Perfect for bridging the time until October/November when Windows 10 hopefully uses OpenConsole as its default conhost.

conhost is built from the (exact!) same source as OpenConsole; one is just delivered a lot faster since we aren’t stuck behind the multiple-month Windows release cycle 😉

From @parthsdoshi

Here’s a test case that works using cmd.exe but not with alacritty.exe:

  1. Run bash
  2. Run tmux
  3. Make sure tmux mouse mode is on: <Leader> :set -g mouse on
  4. Run dialog --yesno Testing 10 30
  5. Verify clicking works using cmd.exe
  6. Detach tmux: <Leader> d
  7. open alacritty.exe
  8. Run bash
  9. Run tmux a
  10. Run dialog --yesno Testing 10 30
  11. Verify the same does not work in alacritty.

There’s a few simpler test cases too. Open bash through cmd.exe and test vim scrolling. Do the same in alacritty.exe and see that vim won’t receive any mouse input.

I understand this issue is closed, but just for those who came looking like me, I have added a PR to update https://github.com/fredizzimo/alacritty/tree/add_openconsole_support to current master

@xy9485 I recommend trying wezterm, it works great on Windows and has working mouse support.

Is there no progress on this?

Mouse interactions work perfectly fine in wsl+tmux+neovim running on cmd.exe. Works perfectly running on Windows Terminal. And it works running on wsltty. Alacritty is now the odd one out here with mouse events not working.

@habamax I replaced conhost.exe with OpenConsole.exe from Windows Terminal (microsoft/terminal#1817). It works just fine. Don’t forget to restore original permissions (TrustedInstaller as owner, read and execute permission for all other groups & users).

The issues were not fixed on the Windows 20H2 build, at least not for me. And worse, I was no longer able to replace the conhost.exe, since it starts with Windows, and there’s no way to kill it.

So I made this pull request, https://github.com/alacritty/alacritty/pull/4501, which allows you to put the conhost.dll, and OpenConsole.exe files of the Windows Terminal into the Alacritty folder, without having to mess any system files.

Would be nice to get this fixed for Windows 10. I’m on a corporate machine so God knows when we’ll get Windows 11, and obviously I can’t mess with System32

I have personally moved on to Windows 11, where everything seems to be fixed.

Can confirm that the workaround is no longer needed on Windows 11 21H2 and yet still necessary on Windows 10 21H2.

Just so you’re aware: the console host changes here will be released in an upcoming version of Windows (probably not the most immediate one if the build number is <19500), and the changes we made do not support mouse events for Windows applications.

For anyone working on a terminal: The pty hosting infrastructure now hooks the terminal’s input stream directly to the application’s input stream; there’s no more input translation in the “pure VT” case.

We still have a lot of work to do to synthesize windows mouse events for windows applications where we do need translation, but this may be enough to unblock other ConPTY consumers.

@tfriedel Like magic. Thank you for saving me from hours of pain.

may help some people: i made a branch which integrates #4501 from fredizzimo and commit 8d2d1eb from aytey which replaces “\r\n” with “\n” based on version 0.10.1

Any update on this issue? Mouse interaction(click and scroll) is still not working on Windows 21H1.

Thanks. It turns out when I launch Alacritty with ‘-e ssh’ the remote tmux/vim sessions don’t capture the mouse. Launching Alacritty without options, then initiating an ssh session results in the desired mouse capture I need in tmux. The same issue exists in WT and it’s apparently due to https://github.com/PowerShell/Win32-OpenSSH/issues/1310.

I think this issue should be opened, so that it shows up more clearly in the search, preventing duplicates.

Just search closed issues as well, we can’t do anything about mouse on Windows, since it’s not something depending on us. It should just start working at some point, since mouse protocol is implemented for a long time in alacritty.

@anupamsr you’re free to submit what you think is missing upstream, but the @fredizzimo patch was picked up and merged here https://github.com/alacritty/alacritty/pull/6994 . Windows support won’t get better until folks can provide patches for it, because barely no alacritty contributors are developing on windows.

just try older commits.

build from master and add conpty.dll/OpenConsole.exe in the path.

I can’t believe these guys are abandoning Win10 users. I’m stuck on a Win10 corp laptop, like many of us are. Just wanted to tag the thread that as of 10/1/23, the above work-around still works. I used @anupamsr 's fork. Looks like it had too many conflicts to merge into @fredizzimo 's fork (but I’m not GitWizard). Thanks!

Yeah, performance on windows is bottle necked on ConPty. Even macOS alacritty is 10-100x faster than windows build, simply because conpty is too slow.

Wezterm has also compiled the fixed version of conpty: https://github.com/wez/wezterm/tree/main/assets/windows/conhost

Is there no progress on this?

Mouse interactions work perfectly fine in wsl+tmux+neovim running on cmd.exe. Works perfectly running on Windows Terminal. And it works running on wsltty. Alacritty is now the odd one out here with mouse events not working.

See discussions above on replacing C:\Windows\system32\conhost.exe with OpenConsole.exe. It works for me.

I wouldn’t consider that a solution, no one should need to mess with files in system32 just to make a terminal emulator work. I’ve switched to Windows Terminal for now, it works a lot better than Alacrity. Recommend others do the same.

@habamax I replaced conhost.exe with OpenConsole.exe from Windows Terminal (microsoft/terminal#1817). It works just fine. Don’t forget to restore original permissions (TrustedInstaller as owner, read and execute permission for all other groups & users).

Thx, although I am not sure what is conhost.exe and how can I replace it with openconsole.exe

Since alacritty can’t do anything other than wait, closing this issue.

@damnskippy sorry about the confusion! Terminal ships with a bundled version of conhost so that it can leverage improvements to the pty.

@DHowett-MSFT

the console host changes here will be released in an upcoming version of Windows

Sorry if I’m being dense - the note above seems to suggest the mouse input related enhancement is available through the upcoming version of Windows. However my interpretation may not be entirely accurate since latest release Terminal Preview advertises mouse input support which I presume runs the the current Windows release?. I’m not sure. Or are the mouse related enhancements somehow bundled into the Terminal Preview.

For an alacritty user like me on Windows, it sure sounds like waiting for the next Windows release is the only recourse. (Sadly IT at my work is slow to roll out windows upgrades, so seeing mouse input on Alacritty for me is so near and yet so far).

Thanks.

If Alacritty is using the windows pseudoconsole infrastructure (not wsltty(!)), you’re still subject to the limitations mentioned in https://github.com/microsoft/terminal/issues/545#issuecomment-506876814. The system-level support for translating mouse events isn’t there just yet. 😄

I find mouse clicks to be accepted for WSL-tmux (on Windows) via wsltty. Source: https://github.com/microsoft/terminal/issues/545#issuecomment-506876814

Are there special settings for alacritty to enable such mouse features? On wsltty, I even found mouse-clicks to be working for SSH sessions.

Perhaps @zacps or a team member can update the original issue with a link to this, which I suppose can be considered the upstream issue: https://github.com/Microsoft/console/issues/376

@DHowett-MSFT has explained why this doesn’t work (it’s a ConPTY thing, nothing to do with alacritty one bit)