Un clavier USB envoie-t-il uniquement des signaux ou en reçoit-il également de l'ordinateur ?

De la " Définition des classes de dispositifs pour les dispositifs d'interface humaine Devices (HID)" version 11.1 spécification " :

Synchronisation entre les états de la DEL et CAPS LOCK, NUM LOCK, SCROLL LOCK, COMPOSE et KANA est maintenue par l'hôte et NON par le clavier. clavier. Si vous utilisez le descripteur de clavier de l'annexe B, les états des LEDs sont définis par envoi de un rapport absolu de 5 bits au clavier par l'intermédiaire d'un Set_Report(Output).

Pour modifier les voyants du clavier, le clavier accepte une commande à cet effet. Il ne s'agit donc pas d'un périphérique "d'entrée uniquement" (ce qui signifie qu'il ne fait que transmettre des données à l'hôte).

Ceci étant dit, il existe un processus de négociation et d'énumération avec tous les dispositifs USB qui nécessite une conversation en va-et-vient entre l'hôte et le dispositif. Vous ne pouvez pas avoir un périphérique USB en "lecture seule".

Même avant l'USB, le contrôleur de clavier du PC acceptait les commandes parce qu'il faisait quelques choses en plus de lire le clavier ( référence ):

Si le clavier est une unité de système périphérique distincte (comme dans la plupart des ordinateurs de bureau modernes), le contrôleur de clavier n'est pas directement relié aux touches, mais reçoit les scancodes d'un microcontrôleur intégré au clavier via une sorte d'interface série. Dans ce cas, le contrôleur contrôle généralement aussi les DEL du clavier en renvoyant des données au clavier par le biais du câble.

Le PC AT d'IBM utilisait une puce Intel 8042 pour l'interface avec le clavier. Cet ordinateur contrôlait également l'accès à la ligne A20 afin d'implémenter une solution de contournement pour un bogue dans la puce Intel 80286. 1 Le contrôleur de clavier a également été utilisé pour initier une réinitialisation logicielle du CPU afin de permettre au CPU de passer du mode protégé au mode réel. 1 parce que le 286 ne permettait pas à l'unité centrale de passer du mode protégé au mode réel à moins que l'unité centrale ne soit réinitialisée. Cela posait un problème car les services du BIOS et du système d'exploitation ne pouvaient être appelés que par des programmes en mode réel.

Ces comportements ont été utilisés par de nombreux logiciels qui s'y attendaient, et par conséquent, les contrôleurs de clavier ont continué à contrôler la ligne A20 et à effectuer des réinitialisations logicielles du CPU, même lorsque la nécessité d'une réinitialisation via le contrôleur de clavier a été évitée par la capacité de l'Intel 80386 à passer du mode protégé au mode réel sans réinitialisation du CPU.

Tout périphérique USB, quelle que soit sa classe, nécessite une communication bidirectionnelle pour fonctionner. . Chaque périphérique USB (ou fonction en termes de spécification USB) est représenté comme un ensemble de points finaux qui peuvent être considérés comme des tampons qui acceptent ou reçoivent des données. Cependant, même les points d'extrémité qui ne peuvent qu'envoyer des données attendent un paquet spécial appelé jeton avant qu'ils puissent répondre :

(image tirée de aquí Les cases grises représentent l'hôte USB, les cases blanches représentent la fonction USB.)

Même les transferts dits d'interruption sont effectués de cette manière, l'hôte USB interrogeant les périphériques connectés à l'aide de paquets de jetons. La différence entre les transferts réguliers (de masse) et les transferts par interruption est que le temps d'interrogation est faible et garanti dans ce dernier cas. Néanmoins, tous les transferts sont initiés par l'hôte.

La question reflète une idée fausse très répandue selon laquelle les périphériques USB "envoient" quelque chose au PC de leur propre chef lorsqu'une touche est enfoncée (ou que la souris bouge), d'où l'importance de cette attention. En fait, les périphériques USB n'envoient rien tant qu'ils n'ont pas REÇU la demande correspondante de l'hôte. Une exception est le processus de réveil d'un dispositif suspendu.

Si la clé USB semble simple en apparence, son fonctionnement est en fait assez compliqué. Tout nouveau périphérique USB doit d'abord être "recensé" avant de commencer à fonctionner. La séquence est la suivante :

1. Après le branchement d'un clavier, le port hôte reçoit le signal "état de connexion" (pour les signaux LS, D- est tiré vers le HAUT par le clavier).

2. Ensuite, l'hôte met le port en mode "réinitialisation du port" et le PHY USB (pilote de la couche physique) envoie "USB_RESET" sur les lignes D+/D- (les deux lignes sont pilotées vers le bas pendant une durée déterminée). Des informations sur la "réinitialisation du port" pour les dispositifs FS/HS peuvent être trouvées sur le site suivant trouvé ici .

3. Ensuite, l'hôte commence à émettre des paquets de limite de trame à intervalle de 1 ms. Pour les dispositifs à faible vitesse (LS) comme les claviers câblés ordinaires, il s'agit simplement d'impulsions de "maintien en vie", tandis que pour les FS, les paquets spéciaux SOF (start-of-frame) sont générés. Ces paquets maintiennent le dispositif en mode actif et l'empêchent de passer en mode SUSPEND à faible consommation.

4. Puis l'"énumération" commence. L'hôte envoie une requête pour obtenir un descripteur de périphérique. La requête est envoyée à "default pipe" avec l'adresse de périphérique "0". (Il n'y a qu'un seul périphérique de ce type à l'heure actuelle - le clavier - puisque tous les autres périphériques sur le bus devraient déjà avoir leurs adresses USB attribuées individuellement).

5. Le clavier renvoie les informations demandées, afin que l'hôte puisse déterminer quel type de pilote doit être chargé.

6. L'hôte envoie une transaction demandant au dispositif de changer son adresse par défaut en une nouvelle adresse attribuée.

7. Ensuite, l'hôte entame un nouveau cycle de communication avec le dispositif, maintenant à la nouvelle adresse attribuée. Tous les autres périphériques ignorent cette communication car elle ne leur est pas adressée.

8. L'hôte peut lire beaucoup plus d'informations à partir de plusieurs autres descripteurs, et finit par sélectionner "configuration du périphérique". Ceci conclut le processus d'énumération.

9. Selon la classe du périphérique USB, l'hôte commence à communiquer avec le périphérique. Dans le cas d'un clavier, l'hôte envoie essentiellement des requêtes "IN" périodiquement, interrogeant essentiellement le dispositif (même si ce tuyau périodique est appelé tuyau d'interruption). Si une touche du clavier a été enfoncée ou pressée, le clavier renvoie cette information. Dans le cas contraire, aucune donnée ne sera renvoyée au pilote du périphérique.

En bref, chaque dispositif USB doit recevoir une adresse unique de la part de l'hôte USB, et deux hôtes USB auront des difficultés à communiquer avec un dispositif - collision de bus, non-concordance des adresses, interception aléatoire des données de frappe, etc. Le protocole USB rend impossible le partage d'un dispositif entre deux hôtes USB.

Comme d'autres réponses l'ont expliqué, l'USB nécessite une communication bidirectionnelle dans le cadre de son fonctionnement. Le PS/2, tout en permettant la communication bidirectionnelle, ne l'exige pas pour envoyer des touches à l'ordinateur, mais l'exige pour régler les DEL du clavier.

Théoriquement, vous pourriez construire un dispositif pour dupliquer le signal PS/2 et l'envoyer à un deuxième ordinateur, et ignorer toutes les commandes des ordinateurs, de sorte que vous seriez en mesure d'envoyer vos pressions sur les touches à plusieurs ordinateurs, mais les DEL du clavier ne répondraient pas aux états de verrouillage numérique, de verrouillage des majuscules et de verrouillage du défilement (ou tout autre changement d'état des DEL, par exemple sous Linux, les DEL du clavier sont parfois utilisées à d'autres fins).

Je ne suis pas sûr de la complexité d'un tel projet. Cela fait un moment que je n'ai pas travaillé avec PS/2, donc je ne sais pas si vous pourriez simplement faire un pont entre deux fils/connecteurs ou si vous auriez besoin d'un dispositif actif (par exemple un microcontrôleur) pour passer les commandes dans une direction et les rejeter dans l'autre. Si vous aviez un microcontrôleur, vous pourriez même faire en sorte que le dispositif puisse interpréter les commandes des DEL du clavier et les "combiner" pour l'affichage (par exemple, un clignotement long de la DEL si elle est allumée sur l'ordinateur un mais éteinte sur l'ordinateur deux, un clignotement court de la DEL si elle est allumée sur l'ordinateur deux mais éteinte sur l'ordinateur un, une DEL allumée en permanence si elle est allumée sur les deux ordinateurs, et une DEL éteinte si elle est éteinte sur les deux ordinateurs). Mais cela serait plus avancé.

De même, si votre objectif est de pouvoir contrôler un ordinateur à partir d'un autre ordinateur, ou deux ordinateurs à partir du même bureau, ou autre, vous devriez peut-être vous renseigner :

• VNC (permet de contrôler un ordinateur depuis un autre via un réseau)
• RDP (permet également de contrôler un ordinateur à partir d'un autre sur un réseau, intégré à Microsoft Windows mais nécessitant la version professionnelle)
• KVM (une pièce de matériel qui vous permet de commuter un ensemble de périphériques entre deux ordinateurs)

Avant les claviers USB, les claviers PS/2 utilisaient un protocole beaucoup plus simple. Il était possible de connecter un clavier à deux appareils et de les faire fonctionner. Une simple connexion en Y est tout ce qui est nécessaire.

Les claviers USB plus anciens ont toujours un mode d'émulation PS/2 intégré ; l'utilisation d'un de ces adaptateurs de connecteur violet vous permet de le brancher sur un port PS/2 à l'arrière d'un ordinateur. Ainsi, l'utilisation d'un câble USB vers PS/2 sur deux ordinateurs, puis d'un adaptateur violet vers votre clavier USB peut fonctionner.

Les claviers USB plus récents ont abandonné le mode PS/2 traditionnel et ne fonctionneront donc pas dans ce cas.