Mes excuses pour le spam du journal. Si vous ne rencontrez aucun problème pour vous connecter à un appareil avec WebUSB, vous pouvez ignorer ces avertissements. Ils sont déclenchés lorsque Chrome tente de lire les propriétés des périphériques USB actuellement suspendus.
Après avoir parcouru pas mal de discussions, de documentations et de problèmes de Chromium, voici les détails liés à l'apparition du message de journal :
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Détails
Tout a commencé avec le signalement du chrome Supprimer la dépendance de WebUSB sur libusb sous Windows en tant que :
- Pour Linux (probablement Mac également), la notification et la communication WebUSB fonctionnent correctement (après avoir autorisé l'accès de l'utilisateur à l'appareil dans les règles udev).
- Pour Windows, il semble que libusb ne fonctionne qu'avec un pilote WinUsb non standard (https://github.com/libusb/libusb/issues/255).
Lorsque le matériel est inséré et que le VID/PID est inconnu du système, Windows 10 charge correctement son pilote CDC pour la partie CDC et le pilote WinUSB (version 10) pour la partie WebUSB (pas de drapeaux rouges). Cependant, il semble que chrome ne trouve jamais l'appareil jusqu'à ce que je force manuellement un ancien pilote WinUSB (version 6 - probablement également modifié) sur l'interface.
La solution a été implémentée par étapes comme suit :
- Commencer à prendre en charge certains transferts dans le nouveau backend USB de Windows
- Résoudre les transferts groupés/interrompus dans le nouveau backend USB Windows
- [usb] Lire les descripteurs BOS à partir du pilote du concentrateur sous Windows
- [usb] Collecte tous les chemins de périphériques composites lors de l'énumération sous Windows
- [usb] Supprimer les paramètres dans les fonctions d'assistance UsbServiceWin
- [usb] Prise en charge des périphériques composites dans le nouveau backend Windows
- [usb] Détecte les fonctions USB lorsque Windows les énumère
- [usb] Prend en charge les appareils composites avec plusieurs fonctions
- [usb] Retenir les requêtes d'interface jusqu'à ce que Windows énumère les fonctions
- [usb] Ajouter un paramètre de direction à ClearHalt
- [usb] Compter les références à un WINUSB_INTERFACE_HANDLE
- [usb] Mettre en œuvre des opérations de blocage dans le backend Windows
Ces changements garantissaient que le nouveau backend était prêt à être testé et était disponible via Chrome Canary et chrome-dev-channel auquel vous pouvez accéder manuellement via :
chrome://flags#enable-new-usb-backend
D'autres demandes de modification ont été soumises comme suit :
- [usb] Marquer les appels à SetupDiGetDeviceProperty comme potentiellement bloquants :selon les rapports de blocage, cette fonction effectue un appel RPC qui peut prendre un certain temps. Marquez les appels avec une base ::ScopedBlockingCall afin que le pool de threads sache que cette tâche peut être occupée pendant un certain temps.
- variations :Activer NewUsbBackend dans la configuration de test d'essai sur le terrain :cet indicateur était expérimental car le canal bêta utilise cette configuration de modification par défaut pour les tests.
Le lancement expérimental du nouveau backend semblant stable, cette configuration a finalement été activée par défaut afin que le changement s'étende à tous les utilisateurs de Chrome 87 via USB :activez le nouveau backend USB Windows par défaut. Révision / Validation
L'idée était une fois que cette configuration deviendrait la valeur par défaut pour quelques jalons, Équipe Chromium commencera à supprimer le code spécifique à Windows de l'ancien back-end et supprimera l'indicateur.
En avant
Équipe Chrome ont déjà fusionné la révision/commit pour étendre l'expiration du drapeau new-usb-backend dans Chrome v90 qui sera bientôt disponible.
Mettre à jour
Selon le commentaire [Committer, WebDriver for Google Chrome] de @ReillyGrant :
..." il serait bon de réduire le niveau de journalisation de ces messages afin qu'ils n'apparaissent pas sur la console par défaut mais nous n'avons pas encore de code pour le faire"...
Références
Vous pouvez trouver quelques discussions détaillées pertinentes dans :
- Échec de la lecture du descripteur à partir de la connexion au nœud :un appareil connecté au système ne fonctionne pas, erreur lors de l'utilisation de ChromeDriver Selenium sur le système d'exploitation Windows
- Échec de la lecture du descripteur à partir de la connexion au nœud :un périphérique connecté au système ne fonctionne pas, erreur lors de l'utilisation de ChromeDriver Chrome via Selenium
