Linux 7.3 va commencer à vérifier si votre câble USB-C sait réellement porter un mode alternatif avant que le noyau n'en annonce un. Jusqu'ici il ne regardait pas, ce qui explique qu'un écran branché via un câble de charge pouvait vous laisser un port affirmant que DisplayPort est configuré alors que rien n'apparaît. Le nouveau code, signé Andrei Kuchynski de l'équipe Chrome OS de Google, inspecte trois choses : la présence d'un en tête d'identité, le fait qu'un câble passif soit limité aux débits USB 2.0, et le fait qu'un câble actif déclare les fiches correspondantes. Petit changement, qui supprime une classe de pannes réellement déroutante.
The short answer
Linux 7.3 ajoute la validation des capacités du câble USB Type-C avant que le noyau n'engage un mode alternatif comme DisplayPort ou Thunderbolt. Les noyaux précédents n'inspectaient pas ce que le câble pouvait porter, ce qui autorisait des configurations d'état annoncées à tort et des échecs d'initialisation. Le nouveau code cherche un en tête d'identité, repère les câbles passifs limités aux débits USB 2.0, et exige des câbles actifs qu'ils déclarent leurs fiches. Il vient d'Andrei Kuchynski, de l'équipe Chrome OS de Google. Linux 7.3 apporte aussi une option busy_poll pour USB4STREAM et des descriptions Device Tree pour le contrôleur DWC3 de l'ASpeed AST2700.
Si vous avez déjà branché un écran sur un portable en USB-C, obtenu un écran noir, changé pour un câble d'apparence identique et vu l'image apparaître, vous avez rencontré ce défaut. Linux 7.3 ne répare pas le câble. Il empêche le noyau d'affirmer que le premier convenait.
La faille que cela comble
Les modes alternatifs USB Type-C permettent à un port de transporter autre chose que du trafic USB, le plus souvent DisplayPort et Thunderbolt. Que cela fonctionne dépend autant du câble que des deux appareils, car porter ces signaux réclame des conducteurs et, pour les câbles actifs, une électronique qu'un simple câble de charge n'a tout bonnement pas.
Jusqu'à Linux 7.3, le noyau ne vérifiait pas. Il engageait le chemin du mode alternatif quelles que soient les capacités du câble, et l'issue prenait l'une de deux formes peu utiles : une configuration d'état annoncée qui ne correspondait pas à la réalité physique, ou un échec d'initialisation sans cause évidente. Aucune des deux ne disait la chose utile, à savoir que le câble n'est pas le bon.
Les trois contrôles
Andrei Kuchynski, de l'équipe Chrome OS de Google, a ajouté une validation qui s'exécute avant l'annonce d'un mode.
Le noyau vérifie la présence d'un en tête d'identité. Un câble incapable de s'identifier en Power Delivery n'est pas un câble sur lequel on construit un lien Thunderbolt. Il vérifie si un câble passif est limité aux débits USB 2.0, signature du câble de charge fourni gratuitement dans une boîte. Et pour les câbles actifs, il vérifie que les fiches correspondantes sont déclarées, car un câble actif qui ne décrit pas ses fiches ne décrit pas un chemin fonctionnel.
Si l'un de ces points échoue, le mode n'est pas proposé. Résultat pratique : la panne se déplace du bout lointain, où vous fixez un écran noir, vers le bout proche, où le port cesse simplement de revendiquer une capacité qu'il ne peut pas tenir.
Le voir depuis l'espace utilisateur
L'information sur laquelle agit le noyau n'est pas cachée. La classe connecteur USB Type-C expose les propriétés du câble dans sysfs, ce qui fait de ce changement l'un des rares que vous pouvez inspecter sur votre propre bureau sans rien instrumenter.
Sous /sys/class/typec/ vous trouverez une entrée câble par port, en général port0-cable. L'attribut type rapporte passif ou actif. L'attribut plug_type donne le connecteur. L'attribut usb_power_delivery_revision indique la révision Power Delivery en jeu, et le répertoire identity contient les objets bruts définis par le fabricant, dont id_header. Si un mode attendu cesse d'être proposé après le passage en 7.3, la réponse se trouve dans ces fichiers, et ce sera le plus souvent que le câble ne s'était jamais correctement identifié.
Le reste du travail USB dans la 7.3
Deux autres éléments arrivent en même temps.
Intel a contribué une option busy_poll pour USB4STREAM, un réglage ConfigFS qui fait tourner les anneaux de transfert en scrutation plutôt que sur interruptions. Il réduit la latence d'hôte à hôte entre systèmes reliés en USB4 ou Thunderbolt, au prix d'une charge processeur nettement plus élevée, ce qui en fait une option que l'on active pour une charge de travail précise plutôt qu'un réglage permanent.
Arrivent aussi de nouvelles descriptions Device Tree pour le contrôleur DWC3 de l'ASpeed AST2700. Celle ci vise le matériel serveur et les contrôleurs d'administration plutôt que les portables, et c'est le genre d'entrée qui décidera discrètement, dans deux ans, si une carte d'administration fonctionne dès le premier démarrage.
Pourquoi un petit correctif mérite qu'on en parle
Le comportement des câbles est l'une des choses les moins gratifiantes à déboguer, car chaque symptôme désigne le mauvais composant. Un écran externe mort ressemble à un problème de pilote graphique. Un périphérique Thunderbolt qui refuse de s'énumérer ressemble à un problème de micrologiciel. C'est un thème récurrent du travail d'activation matérielle cette année, de la mise en service de Thunderbolt et des webcams sur silicium Apple par Asahi Linux aux efforts de micrologiciel ouvert sur les stations d'accueil USB4.
Un noyau qui refuse d'annoncer un mode que le câble ne peut pas porter n'accélère rien. Il rend le système honnête, et sur cette catégorie de matériel cela vaut davantage.
Sources et pour aller plus loin
- Linux 7.3 Will Begin Checking USB-C Cables For Alt-Mode Support, Phoronix, 28 août 2026
- USB Type-C mode selection, LWN.net
- USB Type-C connector class, documentation du noyau
- Documentation ABI sysfs-class-typec
Questions fréquentes
Que vérifie exactement Linux 7.3 désormais ?
Trois conditions avant d'annoncer un mode alternatif. D'abord, la présence d'un en tête d'identité du câble, car un câble incapable de s'identifier n'est pas un câble sur lequel on bâtit un mode à haut débit. Ensuite, le fait qu'un câble passif soit limité aux débits USB 2.0, signature des câbles de charge livrés dans les boîtes de téléphones et de chargeurs. Enfin, pour un câble actif, la déclaration des fiches correspondantes, car un câble actif qui ne décrit pas ses fiches ne décrit pas un chemin fonctionnel. Si l'une des vérifications échoue, le noyau n'annonce pas le mode.
Quel problème cela corrige t il ?
Des configurations d'état annoncées à tort et des échecs d'initialisation. Sans ces contrôles, le noyau pouvait engager une négociation de mode alternatif avec un câble incapable de le porter, et le résultat était soit un état affirmant que DisplayPort ou Thunderbolt était configuré alors que rien ne marchait, soit un échec d'initialisation sans cause visible. Vu de la place de l'utilisateur, cela ressemble à un écran externe qui reste noir avec un câble et fonctionne avec un autre, sans raison apparente. Le changement ne fait pas fonctionner le mauvais câble : il empêche le noyau de faire semblant d'y croire.
Est ce que cela va casser des stations d'accueil ou des écrans qui marchent aujourd'hui ?
Ce ne devrait pas être le cas, car les contrôles décrivent ce qu'un câble doit savoir faire plutôt que d'ajouter une exigence nouvelle. Un câble qui porte réellement le mode alternatif DisplayPort présente une identité, n'est pas un câble passif USB 2.0, et déclare ses fiches s'il est actif. Ce qui peut changer, c'est le comportement de matériels limites qui négociaient auparavant quelque chose qu'ils ne pouvaient pas tenir. Si une installation cesse d'annoncer un mode après la mise à jour, c'est le câble qu'il faut remplacer en premier, pas le noyau.
Comment voir ce que déclare mon câble ?
La classe connecteur USB Type-C l'expose dans sysfs. Regardez sous /sys/class/typec/ les entrées du type port0-cable : l'attribut type indique passif ou actif, plug_type donne le connecteur, et usb_power_delivery_revision rapporte la révision Power Delivery utilisée. Sous le répertoire identity vous trouvez les objets bruts définis par le fabricant, dont id_header. Lire ces attributs vous dit ce que le noyau a appris du câble, c'est à dire l'information exacte sur laquelle agissent les nouveaux contrôles, donc c'est le chemin le plus rapide pour comprendre pourquoi un mode est proposé ou non.
Quoi d'autre a changé côté USB dans Linux 7.3 ?
Deux points à connaître. Intel a ajouté une option busy_poll à USB4STREAM, un réglage ConfigFS qui fait tourner les anneaux de transfert en scrutation plutôt que sur interruptions, réduisant la latence d'hôte à hôte sur USB4 ou Thunderbolt au prix d'une charge processeur plus élevée. C'est un arbitrage que l'on fait volontairement plutôt qu'un réglage à laisser actif. Il y a aussi de nouvelles descriptions Device Tree pour le contrôleur DWC3 de l'ASpeed AST2700, ce qui compte si vous travaillez sur des contrôleurs d'administration de serveurs plutôt que sur des portables et des stations d'accueil.