Vraiment, l’implémentation la plus moderne de DisplayPort est l’altmode USB-C DisplayPort, synonyme de « vidéo sur USB-C », et nous manquerions si je devais l’ignorer. Incidemment, nos deux derniers articles sur l’USB-PD parlant ont donné à quelques personnes un nouveau jouet sympa avec lequel jouer – des gens ont commenté les articles, m’ont contacté pour obtenir de l’aide pour le débogage, et j’ai même vu des gens intégrer le FUSB302B dans leurs projets ! Dans la foulée de cette réalisation, allons plus loin et conquérons une autre fonctionnalité USB-C – une fonctionnalité qui n’est pas encore ouvertement disponible pour que nous puissions la pirater, même si elle mérite de l’être.
Pour nos lecteurs de longue date, il n’est pas surprenant de voir des capacités banales refusées aux pirates. À l’heure actuelle, nous savons tous que de nombreux ordinateurs portables et téléphones vous permettent d’obtenir une connexion DisplayPort à partir d’un port USB-C. Étant donné que les spécifications USB-C sont librement disponibles et que nous avons précédemment implémenté un récepteur PD utilisant ces spécifications, vous vous attendez à ce que nous puissions faire DisplayPort avec la même facilité. Pourtant, la spécification DisplayPort altmode est à l’origine d’un mur payant d’adhésion VESA, avec un prix élevé – une pratique qui a été largement critiquée, contraire à leur objectif en tant qu’organisation de normalisation et ayant entraîné l’échec de certaines de leurs normes.
Ne vous inquiétez pas, cependant – nous pouvons facilement trouver un assortiment de fichiers PDF donnant un aperçu de haut niveau et quelques détails sur l’altmode DisplayPort, et voici mon préféré ! J’ai également un appareil exécutant MicroPython avec une puce FUSB302 connectée, et quelques appareils DisplayPort altmode que je peux démonter. Ceci, s’avère, est plus que suffisant pour que nous procédions à la rétro-ingénierie dans une bibliothèque altmode DisplayPort open source !
Principes de base de DisplayPort sur USB-C
Le port USB-C comporte quatre paires haut débit et une paire auxiliaire bas débit (SBU). Cela correspond parfaitement aux exigences DisplayPort, avec jusqu’à quatre paires de transfert de données à haut débit et un canal de configuration AUX. Une petite bizarrerie – il n’y a pas de broche pour le signal HPD ; au lieu de cela, son état est transmis à l’intérieur des messages altmode DisplayPort sur le canal PD. En conséquence, vous pouvez brancher votre appareil sur un USB-C compatible DisplayPort, écrire quelques mots magiques sur PD et obtenir un signal DisplayPort sur les broches USB-C TX/RX ! Pas besoin de se plonger dans les composants internes de DisplayPort ; le plus dont vous aurez besoin est de transmettre HPD en tant que message PD, et si votre appareil utilise une prise USB-C, demandez à un mux bon marché d’inverser les signaux en fonction de la façon dont votre câble USB-C est branché.
Outre DisplayPort, vous bénéficiez également de l’USB 2.0 sur les bonnes vieilles broches USB2 – parfait pour brancher un clavier et une souris à côté de votre moniteur. Ce n’est pas tout ce que vous pouvez extraire, cependant – si vous vous contentez d’un DisplayPort à deux voies, vous pouvez demander au périphérique en amont de vous fournir deux voies de DisplayPort sur une paire de broches et un port USB3 sur une autre ! C’est ainsi que fonctionnent la majorité des stations d’accueil USB-C bon marché – elles obtiennent deux voies de DisplayPort utilisées pour VGA ou HDMI, USB3 pour un port haut débit ou quelques périphériques, et USB2 pour tout un tas d’autres choses, gérant votre entrée d’alimentation sur le côté.
À en juger par le PDF que nous avons de ST, il existe sept types de messages PD auxquels nous devons répondre si nous voulons construire un appareil DisplayPort – le schéma de la page 13 les montre tous. Dans l’article « Tout sur l’USB-C : Répondre à un PD de bas niveau », nous avons appris deux types de messages : Source_Capabilitiesdont une publicité de profil d’alimentation USB-C PSU, et le Request message, que nous avons conçu pour obtenir l’un de ces profils d’alimentation et obtenir une tension plus élevée d’un port USB-C. De deux à sept, c’est tout à fait à notre portée !
Que devons-nous faire pour le désosser, au strict minimum ? Je dirais que le PDF semble contenir plus qu’assez d’informations à lui seul – le flux de communication, les différents codes de commande et le contenu y sont décrits. Cependant, ce sera beaucoup plus confortable si nous voulons avoir des captures de paquets à référencer !
Paquets en captivité
Le reniflage des communications USB-C est un domaine sous-exploré, en particulier si des signaux à haut débit sont impliqués. Pour ceux-ci, vous avez besoin d’une carte intercalaire qui préserve l’intégrité du signal tout en vous permettant de puiser dans les broches CC, et celles-ci ne sont pas tout à fait une douzaine. En ce qui concerne les outils commerciaux pour le reniflage USB-C, j’ai l’impression que la plupart d’entre eux sont tarifés en tenant compte du fait que beaucoup de gens ne comprennent pas l’USB-C. Cependant, il y a certainement des moyens de contourner cela – dans la section des commentaires du premier article parlant de PD, [WF] nous a indiqué un moyen de renifler des paquets USB-C arbitraires avec un analyseur logique et un simple circuit supplémentaire, avec l’aide de sigrok et Pulseview ! Nous fabriquons un appareil qui peut parler DisplayPort altmode, pas seulement le renifler, mais si vous souhaitez accéder à un de vos appareils pendant que vous suivez cet article, cela devrait suffire.
Cela dit, il pourrait y avoir une solution encore plus simple, si vous avez suivi, vous pourriez simplement posséder un FUSB302B, qui est un IC PHY USB-C. Depuis la publication de l’article « Replying PD », j’ai lentement développé les capacités de ma « pile » USB-PD MicroPython personnelle – un assortiment de fonctions et de code PD, mais je l’appellerai une pile jusqu’à ce qu’un nom plus approprié soit trouvé. Tout d’abord, j’ai ajouté la capacité d’écoute des paquets – en passant le FUSB302 en mode réception uniquement, en lisant son FIFO d’entrée aussi rapidement que possible et en analysant les données à la volée. J’ai également ajouté l’analyse des informations sur les paquets, afin que vous puissiez voir les communications USB-C dans la console série, sans avoir à les lire au préalable.
Il y a une mise en garde, bien sûr – je ne peux pas facilement faire de capture passthrough de paquets USB-C, car je ne voulais pas concevoir une carte passthrough open source avec une capacité de prise CC, et ces cartes ne sont pas tout à fait disponibles. Cela dit, quelqu’un devrait le faire – c’est un peu dommage que le périphérique USB-C-Thru n’ait jamais été financé ! Au lieu de cela, j’ai commencé par désassembler les périphériques de câble captif que je possède, puis en tapant sur la broche CC – car, avec un périphérique de câble captif, il n’y a qu’une seule broche CC possible. Cela signifie que je n’ai pas besoin de détecter automatiquement la rotation, ce qui est bien car, étant donné le temps que mon code MicroPython pourrait prendre pour comprendre la rotation, la conversation USB-PD pourrait déjà être terminée à ce stade. Donc, le CC1 de ma carte est câblé à l’une des broches CC de ma station d’accueil USB, CC1 codé en dur pour être la broche d’écoute – quoi d’autre ?
Vous voudrez désactiver les pullups FUSB – ils vont être contre-productifs ici, car nous exploitons un arrangement pullup/pulldown existant, et l’introduction d’un autre pulldown entraînera la désactivation de VBUS. Vous voudrez également désactiver les réponses GoodCRC – FUSB302 les fait automatiquement, ce qui aide lorsque nous l’utilisons comme un évier, mais ici, elles entreront en conflit avec les réponses GoodCRC des deux côtés de la conversation USB-C ; désactiver l’émetteur c’est encore mieux. J’ai également activé la réception de paquets SOP’/” – ces paquets sont utilisés pour les emarkers, et bien que nous n’ayons normalement pas besoin de les recevoir, il est bon de pouvoir les renifler maintenant.
Maintenant, nous sommes prêts ! Attention, les communications USB-C se déroulent très rapidement. Mon code MicroPython n’est pas rapide non plus – j’utilise MicroPython parce que j’ai choisi le piratage plutôt que la vitesse d’exécution. Cependant, par conséquent, je ne peux pas tout à fait analyser les paquets à mesure qu’ils arrivent – je manquerai des parties de la conversation USB-C si je le fais, car, rappelez-vous, même les déclarations imprimées prennent un peu de temps. Au lieu de cela, je lis le contenu FIFO d’entrée aussi rapidement que possible, stocke les paquets dans la RAM et les analyse ensuite. En revanche, avoir des captures de paquets dans la RAM signifie également que je me retrouve avec des enregistrements de conversation PD que je peux facilement stocker et rejouer plus tard, et vous obtenez également quelques-unes de ces captures !
Il y a bien sûr des inconvénients à utiliser cette méthode de capture de paquets – je ne pourrai peut-être toujours pas capturer les communications qui se produisent trop rapidement, je ne capture que les paquets avec un CRC valide et je manquerai tous les paquets tronqués, et je n’ai pas d’horodatage pour les paquets reçus ; l’utilisation d’un analyseur logique annulerait tout cela. Cependant, pour nos objectifs DisplayPort RE, c’est plus que suffisant, et tout code d’analyse que j’écris sera très utile lors de la création d’une bibliothèque. Broche CC câblée, code en cours d’exécution et prêt, c’est parti !
C’est du gazon VDM
Ici, vous pouvez voir une négociation de profil de puissance se produire – Source_Capabilities, Request, Accept et PS_RDY, des choses que nous avons déjà faites auparavant. Ceux-ci sont nécessaires si vous devez parler de PD à quelque fin que ce soit, ce n’est donc pas vraiment une surprise. Cependant, il y a aussi tout un tas de Vendor_Defined messages, et ceux-ci pourraient vous mettre sur les nerfs. N’ayez pas peur, cependant – soyez plutôt reconnaissant envers la norme USB-C, car, avec la façon dont elle indique aux fournisseurs de mettre en œuvre des communications spécifiques aux fournisseurs, ces messages sont mieux documentés que vous ne le pensez !
Les VDM, ou messages définis par le fournisseur, sont responsables de toute invocation d’altmode qui va au-delà des choses habituelles « USB3, USB2 et PD » que vous pouvez obtenir – vous pouvez utiliser les VDM pour tout ce qui ne respecte pas la norme, des altmodes personnalisés aux mises à jour du micrologiciel. Vous pouvez les avoir non structurés ou structurés – les messages non structurés sont essentiellement de forme libre, tandis que les messages structurés sont une sorte de modèle pour une conversation typique qu’un fournisseur pourrait réellement vouloir mettre en œuvre. La négociation DisplayPort utilise des messages structurés, et sur les sept commandes impliquées dans la configuration de l’altmode DisplayPort, cinq d’entre elles sont des commandes déjà définies dans la norme USB-C ! Quant aux deux autres, le PDF que nous avons, mentionne très utilement leurs codes à la page 8, et les décrit plus en détail à la page 10-12.
Ces commandes sont un peu spéciales – ce n’est pas seulement qu’une réponse GoodCRC est requise, le FUSB302B s’en chargera pour nous, de toute façon. C’est aussi que chaque commande peut être une requête ou une réponse, et l’une ou l’autre des directions peut transporter des données supplémentaires, selon la commande spécifique utilisée ! Heureusement, toutes ces données facultatives sont décrites dans le PDF – qui s’est avéré de plus en plus utile au fur et à mesure que nous approfondissons.
Dans l’ensemble, nous n’aurons pas besoin de faire autant de rétro-ingénierie, en particulier – le principal problème, à mon avis, serait les champs de bits. De plus, comme nous n’avons pas la spécification complète, nous pourrions faire une erreur cruciale ou deux – par exemple, nous ne savons pas à quelle vitesse nous devons répondre à ces commandes, ou les spécificités de la gestion correcte du signal DisplayPort HPD. Nous pouvons cependant les comprendre, et j’ai une grande variété de périphériques DisplayPort USB-C pour obtenir des captures de paquets !
Replay Works – Temps de mise en œuvre approprié
Eh bien, nous avons maintenant des commandes de conversation DisplayPort, capturées à partir d’un appareil réel – si nous voulions créer un récepteur DisplayPort en ce moment, nous pouvons simplement les rejouer, en ajustant uniquement de petites choses comme l’ID de message ! En fait, voici un morceau de code qui fait exactement cela – renvoie les commandes que nous avons capturées, et j’ai réussi à le faire invoquer l’altmode DisplayPort sur mon propre ordinateur portable ! Maintenant, je n’ai pas vérifié la sortie DisplayPort haute vitesse, mais j’ai eu une tension sur les broches SBU, ce qui signifie que le diffpair AUX a été câblé à celles-ci – quelque chose qui ne se produit qu’après l’appel réussi du mode alternatif DisplayPort.
La partie fondamentale du code de relecture est la boucle requête-réponse, qui s’appuie sur notre code d’analyse pour répondre aux messages entrants. C’est très bien pour nous – nous aurons exactement besoin de ce type de boucle une fois que nous pourrons réellement construire nos propres réponses, juste que nous aurons besoin d’une boucle un peu plus sophistiquée. Jusque-là, c’est suffisant pour me débrouiller quand il s’agit d’un de mes projets personnels.
Les tâches suivantes consistent à donner un sens à ces commandes et à implémenter une bibliothèque DisplayPort significative ! Nous passerons en revue les sept commandes requises, expliquerons chacune d’elles, analyserons celles que nous recevrons et implémenterons celles que nous devrons renvoyer. Ensuite, nous les lierons tous ensemble dans la boucle déjà existante, déterminerons la gestion de la rotation des voies à grande vitesse USB-C, et nous serons prêts à créer des dispositifs de gestion DisplayPort open source pour tout port USB-C compatible en vue. Après tout, de nos jours, même un PinePhone peut faire du DisplayPort !
