Terminal: [Conpty] Ajout de la prise en charge de la saisie à la souris

Salut @wez ,
Malheureusement, ConPTY ne transmettra pas les rapports de souris (ou, à partir d'une application hébergée, les _demandes de rapports de souris_). Nous avons un élément de backlog qui suit cela et nous espérons y arriver bientôt.

Malheureusement, nous ne pouvons pas simplement transmettre les événements de souris codés : puisque ConPTY peut héberger des applications de console Windows standard, comme celles qui s'attendraient MOUSE_EVENT ce que ReadConsoleInput , nous allons besoin de faire une traduction.

À tous les autres égards, cependant, il semble que vous configurez correctement la pseudoconsole.

Suivi : MSFT : 20469462

@DHowett-MSFT merci pour la réponse !
C'est un peu décevant que les rapports sur les souris ne soient pas encore là, mais c'est quand même bien que le reste des trucs pty soit possible maintenant!

Je n'ai rien à ajouter à part vouloir vraiment prendre en charge la souris avec ConPTY. Avec alacritty maintenant la prise en charge de ConPTY en utilisant alacritty + ssh + tmux est un terminal Linux incroyable sur Windows, seule la prise en charge de la souris manque maintenant.

Je suis un grand utilisateur de minuit commander dans mon shell bash Ubuntu où cela fonctionne TRÈS. Malheureusement, l'onglet du shell Ubuntu du terminal Windows 0.3.2171.0 ne semble envoyer AUCUN événement de souris à l'application mc, ce qui rend son utilisation extrêmement difficile pour moi. J'allais poster un bug, mais je le ferais dupliquer.

Pour mon utilisation, l'envoi d'événements de souris est de la plus haute importance pour une bonne expérience avec vim et tmux.

Je laisse simplement tomber mon soutien pour cela ici, plus un peu de contexte. Au cours du mois dernier, j'ai arrêté le double démarrage et j'ai commencé à utiliser l'anneau "rapide" des builds d'initiés de Windows 10 comme ma machine personnelle principale. Sur ce, j'ai wsl2 qui fonctionne parfaitement, x410 qui fonctionne parfaitement, le terminal Microsoft qui fonctionne très bien, le code visual studio wsl2 qui fonctionne parfaitement et l'interop explorer.exe qui fonctionne parfaitement.

Ce ticket d'entrée de souris est à peu près la seule chose qui m'empêche d'appeler le terminal wsl2 / microsoft un remplacement raisonnable pour avoir une partition / boîte de développement séparée. Étant donné que certains spots ici sont open source, existe-t-il des indications sur la façon de voir les entrées du périphérique de la souris quelque part dans /dev ou devrais-je simplement m'accrocher ?

Merci pour tout ça en tout cas ! j'aime beaucoup sinon :)

Un vote de plus pour dire/demander que le support de la souris serait si doux, et manque cruellement à tous ceux qui utilisent tmux, bien qu'ils puissent en quelque sorte s'en passer.

S'il vous plaît, veuillez activer le support de la souris 😄

@DHowett-MSFT, désolé pour le bourrin, est-il prévu de résoudre ce problème de sitôt? Voir les étiquettes/priorités attribuées à d'autres problèmes, mais ce n'est pas l'un d'entre eux, alors il suffit de vérifier. Merci.

@damnskippy La priorité est attribuée aux choses que nous devons corriger dans l'hôte de la console Windows intégrée (en raison des délais de bogues internes). Il s'agit d'une fonctionnalité _énorme_ (et nécessite une spécification à l'échelle appropriée) et bien que nous sachions que nous en avons besoin pour la v1.0, nous n'y travaillons pas activement aujourd'hui.

Si nous pouvions simplement le "réparer" comme un bogue, j'adorerais ça - mais il faut bien plus qu'un correctif.

Merci pour la mise à jour. Votre travail est apprécié.

J'aime ce que vous faites ici, je l'aime, mais jusqu'à ce que nous obtenions le support de la souris, nous devons compléter ce terminal avec un autre terminal, ce qui va quelque peu à l'encontre de l'objectif de ce terminal.

Midnight Commander sans cela est un cauchemar.

La saisie de la souris en général pourrait être utile, par exemple si un membre de la communauté créait un complément et un profil DosBox qui pourraient s'exécuter dans le terminal Windows.

Je suis un gros utilisateur de vim ; même le support de la souris me manque

Je viens de lire la mise à jour du blog @cinnamon-msft, semble-t-il que l'équipe vise la version 1.0 d'ici la fin de cette année ? Cela signifie-t-il que nous obtiendrons un support de souris d'ici la fin de l'année ? Si oui, y travaille-t-il activement en ce moment ?

Cela signifie-t-il que nous obtiendrons un support de souris d'ici la fin de l'année ?

Peut-être, mais pas de commit dur. Estimer combien de temps il faut au logiciel pour le faire est à peu près aussi difficile que de prouver P==NP. J'irais jusqu'à dire que le terminal ne serait pas prêt pour la version 1.0 sans cela.

Si oui, y travaille-t-il activement en ce moment ?

Pas actuellement. Personne n'est affecté à la tâche, et généralement, lorsqu'un membre de l'équipe termine une tâche, il s'attribue lui-même.

Par curiosité, est-ce qu'il faut tout pour faire ça ici ? Un développeur ambitieux (lire : fou) pourrait-il s'en charger et faire un PR ?

Bien sûr, quelqu'un d'ambitieux pourrait absolument essayer cela par lui-même. Où commencer?

Tout d'abord, permet de décrire une certaine portée. Il y a beaucoup de travail à faire avec la saisie de la souris, il serait donc préférable de commencer petit et de travailler sur des pièces pour arriver à une solution complète. Je pense que la première chose que nous devrions faire fonctionner est de simples séquences haut/bas de souris encodées SGR . Nous pouvons travailler sur les événements de la molette de la souris, puis peut-être survoler, après cela, mais cliquer, je pense, résoudra la plupart des cas d'utilisation.

Commencez par jeter un œil à InputStateMachineEngine.cpp . Le InputStateMachineEngine est responsable de l'analyse des entrées envoyées sur conpty et de leur traduction en INPUT_RECORD s. Un jeune développeur entreprenant souhaiterait modifier cette classe pour pouvoir également analyser ces séquences de souris et les traduire en INPUT_RECORD s. Une fois que vous avez les INPUT_RECORD s, appelez InteractDispatch::WriteInput . Cela ajoutera ces INPUT_RECORD au tampon d'entrée. Une fois qu'ils sont dans le tampon d'entrée, ils seront normalement livrés à l'application cliente de la console connectée.

Choses auxquelles je ferais attention :

• conhost peut ne pas du tout insérer MouseEvents dans le tampon à moins que nous ne soyons en mode d'entrée de souris. Si tel est le cas, nous devons nous assurer d'ignorer également ces séquences.
• Les applications qui veulent une entrée de souris de VT n'obtiendront pas un flux de INPUT_RECORD s, mais un flux de caractères. À un moment donné dans conhost, nous essayons de traduire ces INPUT_RECORD s de souris en un flux de caractères, si l'application attachée est en mode souris VT. Si nous effectuons cette traduction _avant_ les événements de la souris sont dans le tampon, alors faire ce qui précède pourrait ne pas fonctionner pour les applications VT (lire : wsl ). Si tel est le cas, nous devrons nous assurer que la traduction des événements de souris INPUT_RECORD de souris en événements de souris codés VT est effectuée manuellement pour les événements de souris générés par le InputStateMachineEngine .
  
  
  
  • En y regardant de plus près, cela semble être le cas. Malheureusement, nous traduisons uniquement les entrées de la souris pour les événements initiés par la fenêtre. Voir ce code :
    
    https://github.com/microsoft/terminal/blob/2c8b3243dca0c48dd05ecd7b420a7a03b3e19c93/src/interactivity/win32/windowio.cpp#L113 -L129
    
    terminalMouseInput.HandleMouse synthétisera les séquences VT pour l'application cliente, mais elle n'est malheureusement appelée que depuis le proc de la fenêtre. Donc, nous devrons d'une manière ou d'une autre exposer un moyen pour que le InputStateMachineEngine appelle (via une nouvelle méthode sur InteractDispatch ), et si cette méthode échoue, générer le INPUT_RECORD approprié
  
  
  • Techniquement, quelqu'un pourrait déplacer l'appel terminalMouseInput.HandleMouse à la place de la lecture du InputBuffer, et le faire essayer de traduire les INPUT_RECORD s comme ils sont lus, mais cela pourrait être plus compliqué.
  
  

Quel est le problème avec ce problème? La souris fonctionne parfaitement dans l'ancienne console Windows. Cela signifie-t-il que je dois rester avec la console jusqu'à ce que cela soit résolu?

Si vous avez besoin de la prise en charge de la souris VT, oui.

Juste pour info à tous les membres de la communauté qui ont peut-être étudié cela (/cc @SamuelEnglard!), Nous avons officiellement réservé du travail à l'équipe de développement pour le faire. J'espère qu'on ne vous marche pas sur les pieds !

J'y ai pensé, mais je n'ai pas pu réserver mon propre temps donc parfait lol!

Je jouais juste avec VSCode avec les extensions de développement à distance et j'ai découvert que le terminal intégré prend en charge le mode souris dans tmux ! La sélection de panneau, la sélection de fenêtre, le redimensionnement de panneau et la molette de défilement prennent en charge tous les travaux. Je suis nouveau dans ces projets, donc je ne sais pas si le terminal fait partie de l'open source VS Codium et peut être utilisé comme point de départ... désolé si ce n'est pas vraiment utile.

Juste pour info à tous les membres de la communauté qui ont peut-être étudié cela (/cc @SamuelEnglard!), Nous avons officiellement réservé du travail à l'équipe de développement pour le faire. J'espère qu'on ne vous marche pas sur les pieds !

@DHowett-MSFT @zadjii-msft @bitcrazed Votre communication sur cette question ici et ailleurs a été fantastique ; c'est un exemple pour impliquer avec succès la communauté dans la construction de votre logiciel et cela se voit. Votre ou vos équipes (console/WSL/msft-linux) sont personnellement responsables de l'installation de Windows (non nix) dans mon entreprise. Continuez votre travail remarquable 🥇

@thinkjrs Merci beaucoup pour vos aimables paroles.

Et nos plus sincères remerciements à vous et à tous les membres de notre communauté qui exécutent et testent / enregistrent des bogues / soumettent des demandes, des idées et des demandes d'extraction pour Terminal, Cascadia Code, WSL, etc. Vos commentaires nous influencent directement alors que nous priorisons le travail et planifions. et les caractéristiques de conception.

Nous ne plaisantions pas quand nous disons que nous construisons ces fonctionnalités pour et avec notre communauté 😜

Quel est le processus? Existe-t-il des souris fonctionnelles dans WSL ? C'est-à-dire tmux changement de panneau, clic pour changer de canal/serveur en weechat & irssi , (n)vim clics, aptitude clic, htop cliquant, etc.

Quel est le processus? Existe-t-il des souris fonctionnelles dans WSL ? C'est-à-dire tmux changement de panneau, clic pour changer de canal/serveur en weechat & irssi , (n)vim clics, aptitude clic, htop cliquant, etc.

@dmxt Actuellement, j'utilise wsltty qui a été pour moi la plus compatible de toutes les options de terminal. J'ai hâte de passer à Terminal une fois que certaines de ces fonctionnalités seront disponibles.

Quel est le processus? Existe-t-il des souris fonctionnelles dans WSL ? C'est-à-dire tmux changement de panneau, clic pour changer de canal/serveur en weechat & irssi , (n)vim clics, aptitude clic, htop cliquant, etc.

@dmxt Actuellement, j'utilise wsltty qui a été pour moi la plus compatible de toutes les options de terminal. J'ai hâte de passer à Terminal une fois que certaines de ces fonctionnalités seront disponibles.

Je suis d'accord avec votre commentaire, après avoir essayé tous les émulateurs de terminaux connus du public pour Windows au cours des dernières années, pour l'instant au moment de la rédaction, wsltty est le meilleur qui soit. Leur dépôt officiel est également excellent, ils ont un guide formidable pour que je puisse démarrer rapidement. Vous ne pouviez pas demander mieux avec witty, il bénéficiait d'une prise en charge complète de la souris sans aucun problème à travers divers workflows et outils différents.

J'ai remarqué la légère latence dans les E/S et je pense que c'est le goulot d'étranglement du système WSL1. Je suis sous Linux nu et il y a une latence de 0 ms avec l'entrée de la souris.

@dmxt @offero J'ai eu du succès avec XShell (vraie ligne de commande à partir de fonctionnalités expérimentales, ou ssh dans WSL) - prend en charge la souris, etc., juste pour info. Les applications qui nécessitent le support de la souris sont également le commandant de minuit et le micro-éditeur

S'il vous plaît jeter un oeil comment il est résolu dans ConEmu

Une feuille de route ou un calendrier pour savoir quand exactement cela sera, espérons-le, mis en œuvre ? Cela semble être une fonctionnalité assez importante à publier. C'est un peu surprenant pour moi que la v1.0 soit publiée sans que cela soit résolu. Je suppose que le versioning ne veut plus rien dire de nos jours.

@kvnxiao dans la dernière version du Microsoft Store de la souris du terminal Windows est prise en charge (au moins dans Vim), pour autant que je sache

@fat0troll Pour autant que je set mouse=a , la saisie de la souris fonctionne sur l'ancien conhost mais pas sur Windows Terminal 1.0.1401.0.

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

Avec cette configuration vim, je peux cliquer dans la fenêtre de vim et le curseur se déplacera à l'endroit où j'ai cliqué. 1.0.1401.0, Windows build 18368.836 (si cela a un effet sur cela).

@kvnxiao Je vais supposer que vous utilisez OpenSSH_For_Windows_7.7. Il contient un bogue (résolu dans 8.x) qui l'empêche de fonctionner en mode souris.

Nous avons explicitement implémenté cela pour toutes les applications VT qui souhaitent recevoir une entrée de souris.

Je suppose que le versioning ne veut plus rien dire de nos jours.

Il n'y a pas besoin d'être méchant.

En ce qui concerne vim, je l'ai essayé en utilisant neovim construit pour Windows en tant qu'exécutable Windows. Si d'autres disent que le support de la souris fonctionne pour vim (par exemple via ssh / wsl, etc.), alors je ne doute pas de vous, mais cela montre que le support "complet" n'existe pas encore, ce qui pose un problème plus spécifique question:

Que resterait-il dans la feuille de route pour une prise en charge "complète" de la souris par rapport à ce dont conhost est actuellement capable ?

Je parle en termes de volonté de lancer des applications génériques basées sur un terminal qui prennent en charge l'entrée de la souris (et fonctionnent en conhost) via WT. Par exemple, exécuter plusieurs applications d'interface utilisateur basées sur du texte/terminal construites directement en tant qu'exécutable Windows. Ceux-ci fonctionnent bien lorsqu'ils sont double-cliqués pour s'exécuter, ce qui recourt à l'utilisation de conhost, mais lorsqu'ils sont exécutés via le terminal Windows, ils finissent par sélectionner simplement le texte affiché avec la souris.

@niklaskorz Quel est l'intérêt de voter pour et contre les commentaires susmentionnés lorsque des personnes comme moi ont des questions pertinentes concernant ce sujet, qui peuvent ou non être encore non résolues?

Vous avez tout à fait raison. Cet élément de travail, que vous avez correctement identifié comme étant destiné aux applications de console Win32 recevant des événements de souris de n'importe quel terminal, est prévu pour le « terminal 1.x » (jalon), ce qui indique que nous voulons nous y attaquer d'ici la 2.0. Je n'ai pas d'estimation plus précise que celle-là.

Merci pour la clarification! Un peu triste que cet élément de travail n'ait pas pu être concouru pour la 1.0, mais j'attends avec impatience le moment où ce sera le cas, et j'espère que l'attente ne sera pas trop longue 😀.

FIWW, au cas où vous ne le sauriez pas, le nouveau Powershell Out-ConsoleGridView (https://github.com/PowerShell/GraphicalTools) est un cas de test décisif pour cela. Voir le bogue de suivi lié à la souris ici : https://github.com/PowerShell/GraphicalTools/issues/95

Il est construit sur Terminal.Gui (https://github.com/tig/gui.cs).

De plus, nous venons de créer un nouvel exemple d'application pour Terminal.Gui que vous devriez tous pouvoir utiliser pour tester la prise en charge de la souris à mesure qu'elle prend vie dans WT.

Vraiment hâte d'y être!

Y a-t-il un moyen pour que je puisse aider à résoudre ce problème ? C'est une vraie déception pour les applications de console GUI construites avec Terminal.Gui (https://github.com/tig/gui.cs).

@kvnxiao Je vais supposer que vous utilisez OpenSSH_For_Windows_7.7. Il contient un bogue (résolu dans 8.x) qui l'empêche de fonctionner en mode souris.

Nous avons explicitement implémenté cela pour toutes les applications VT qui souhaitent recevoir une entrée de souris.

Je suppose que le versioning ne veut plus rien dire de nos jours.

Il n'y a pas besoin d'être méchant.

Comment puis-je mettre à jour le fichier openssh intégré vers la dernière version ?

@kvnxiao Je vais supposer que vous utilisez OpenSSH_For_Windows_7.7. Il contient un bogue (résolu dans 8.x) qui l'empêche de fonctionner en mode souris.
Nous avons explicitement implémenté cela pour toutes les applications VT qui souhaitent recevoir une entrée de souris.

Je suppose que le versioning ne veut plus rien dire de nos jours.

Il n'y a pas besoin d'être méchant.

Comment puis-je mettre à jour le fichier openssh intégré vers la dernière version ?

Je suppose que vous cherchez quelque chose de décrit dans cet article de blog (Openssh install from chocolatey) : https://blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to- openssh-portable/

Je suppose que vous utilisez OpenSSH_For_Windows_7.7. Il contient un bogue (résolu dans 8.x) qui l'empêche de fonctionner en mode souris.

Nous avons explicitement implémenté cela pour toutes les applications VT qui souhaitent recevoir une entrée de souris.

@DHowett dans ce contexte, il semble que l'utilisation de OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5 devrait fonctionner ?

J'utilise la version de prévisualisation du terminal en SSH sur une machine Ubuntu avec le mode souris tmux activé, mais les entrées de ma souris semblent toujours contrôler uniquement le terminal lui-même.

J'ai également essayé de mettre à niveau le serveur vers OpenSSH 8.0, mais cela n'a pas aidé non plus.

Est-ce que ce problème empêche toujours ce genre de chose de fonctionner?

Ah, le x dans 8.x pourrait être 1. Je ne savais pas qu'ils avaient publié une version 8.0.

Ah, le x dans 8.x pourrait être 1. Je ne savais pas qu'ils avaient publié une version 8.0.

Je vais tenter le coup.

Ça marche! Incroyable, merci !

J'ai commencé à comprendre ce problème.

Malheureusement, MS n'implémente pas encore la fonction de saisie à la souris de l'API Win32 sur le terminal Windows.
(Seule la séquence d'échappement VT est prise en charge.)

J'ai essayé de remplacer ReadConsoleInputW et PeekConsoleInputW dans mon application
pour travailler avec la souris sur le terminal Windows.

Tout d'abord, j'exécute le code suivant.

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

Ensuite, l'entrée de la souris peut être reçue en tant que séquence d'échappement VT (sgr-1006) (par exemple \x1b[<0;10;20M ).

Mais, un autre problème est survenu.

Certaines entrées de touches (telles que les touches fléchées) sont également reçues sous forme de séquence d'échappement VT (par exemple \x1b[A ).

J'ai essayé de convertir ces séquences d'échappement VT indésirables en événement clé de l'API win32,
mais c'est incomplet.
(le code de clé virtuelle et le code de balayage virtuel deviennent par hasard zéro, etc.)

Mon code est ici.
https://gist.github.com/Hamayama/6add968870269f2426716fad79724b31
( PDC_read_console_input_w et PDC_peek_console_input_w sont des fonctions alternatives. )

Je veux une méthode pour désactiver la séquence d'échappement VT, sauf pour l'entrée de la souris.

par exemple

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);

ou

SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_MOUSE_INPUT_ONLY);

Mais, cela pourrait être une mauvaise idée pour l'avenir ...

J'ai trouvé qu'il n'y a pas de suivi du mouvement de la souris dans src/terminal/parser/InputStateMachineEngine.cpp: 391 (traduction des séquences SGR VT en INPUT_RECORD s).

En d'autres termes, le terminal envoie des séquences VT pour ConPTY, mais ConPTY ne surveille que l'état des boutons de la souris. Les modifications des coordonnées de la souris sont ignorées :

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

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

Avec l'état actuel de la prise en charge de la saisie à la souris, l'option suivante est possible.

Vous pouvez ajouter un suivi des coordonnées et le mouvement de la souris commencera à fonctionner dans les applications de console classiques.

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);

Remarque : Avant de démarrer une application console classique, vous devez demander le suivi de la souris au format SGR :

Windows PowerShell

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

Invite de commandes

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

Paramètres

• 1003 - ANY_EVENT_MOUSE_MODE
• 1004 - tout mode non pris en charge (par exemple 1001 ou 9999 ) pour transmettre la séquence via ConPTY au terminal lui-même
• 1006 - SGR_EXTENDED_MODE

en conséquence, le Terminal commencera à envoyer des événements de souris à ConpTY, qui commencera à générer des INPUT_RECORD s pour l'application console classique.

Bonne prise. Nous devrons nous assurer de résoudre ce problème lorsque nous prendrons réellement en charge cela :smile: