Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : Périphériques et systèmes de fichiers Oracle Solaris 11 Information Library (Français) |
1. Gestion des médias amovibles (présentation)
2. Gestion des médias amovibles (tâches)
3. Accès aux médias amovibles (tâches)
4. Gravure de CD et DVD (tâches)
5. Gestion des périphériques (présentation/tâches)
6. Configuration dynamique des périphériques (tâches)
7. Utilisation de périphériques USB (présentation)
Nouveautés concernant les périphériques USB
Prise en charge du descripteur d'association d'interface USB
Prise en charge du transfert isochrone EHCI
Comportement d'enfichage à chaud des périphériques USB
Prise en charge des périphériques USB et 1394 (FireWire)
x86 : Prise en charge des CD et DVD USB pour l'initialisation GRUB
Prise en charge des souris et claviers virtuels USB
Prise en charge d'Oracle Solaris pour les périphériques USB
Présentation des périphériques USB
Acronymes USB couramment utilisés
A propos de l'USB dans SE Oracle Solaris
Caractéristiques des périphérique USB 2.0 et problèmes de compatibilité
Périphériques alimentés par bus
Prise en charge d'une souris à molette USB
SPARC : Gestion de l'alimentation USB
Recommandations concernant les câbles USB
8. Utilisation de périphériques USB (tâches)
9. Utilisation de périphériques InfiniBand (présentation/tâches)
10. Gestion des disques (présentation)
11. Administration des disques (tâches)
12. Système SPARC : Configuration des disques (tâches)
13. Système x86 : Configuration des disques (tâches)
14. Configuration des périphériques de stockage avec COMSTAR
15. Configuration et gestion du service Oracle Solaris iSNS (Internet Storage Name Service)
16. L'utilitaire format (référence)
17. Gestion des systèmes de fichiers (présentation)
18. Création et montage de systèmes de fichiers (tâches)
19. Extension de l'espace de swap (tâches)
20. Copie de fichiers et de systèmes de fichiers (tâches)
Universal Serial Bus (USB) a été développé par le secteur informatique afin de fournir une solution économique pour connecter des périphériques tels que des claviers, des souris et des imprimantes à un système.
Les connecteurs USB sont conçus pour ne recevoir qu'un seul type de câble, dans un seul sens. L'intention de conception principale de l'USB était de réduire la nécessité d'utiliser plusieurs types de connecteurs pour recevoir différents périphériques. Cette conception permet de réduire l'encombrement sur le panneau arrière d'un système.
Les périphériques se connectent aux ports USB sur des hubs USB externes ou sur un hub racine qui se trouve sur l'ordinateur lui-même. Etant donné que les hubs sont dotés de plusieurs ports, plusieurs branches d'une arborescence de périphériques peuvent découler d'un hub.
Pour plus d'informations, reportez-vous à la rubrique usba(7D) ou consultez le site Web à l'adresse suivante :
Le tableau suivant présente les acronymes USB utilisés dans SE Oracle Solaris. Pour une description complète des composants et des acronymes USB, consultez le site Web à l'adresse suivante :
|
La spécification USB est ouverte et libre de droits. Elle définit les interfaces électriques et mécaniques du bus et des connecteurs.
L'USB utilise une topologie dans laquelle les hubs servent de points d'attache aux périphériques USB. Le contrôleur hôte contient le hub racine, qui est le point d'origine de tous les ports USB du système. Pour plus d'informations sur les hubs, reportez-vous à la section Contrôleur hôte et hubs USB.
Figure 7-1 Hiérarchie physique des périphériques USB
La Figure 7-1 présente un système avec trois ports USB actifs. Le premier port USB permet de connecter une clé USB. Le deuxième port USB permet de connecter un hub externe, qui, à son tour, permet de connecter un périphérique CD-RW et un périphérique composite clavier/souris. En tant que périphérique composite, ce clavier contient un contrôleur USB, qui permet de faire fonctionner à la fois le clavier et une souris connectée. Le clavier et la souris partagent la même adresse de bus USB, car ils sont gérés par le même contrôleur USB.
La Figure 7-1 montre également un exemple de périphérique composé, constitué d'un hub et d'une imprimante. Le hub est un hub externe, inclus dans le même boîtier que l'imprimante. L'imprimante est connectée en permanence au hub. Le hub et l'imprimante ont des adresses de bus USB distinctes.
Les noms de l'arborescence des périphériques de certains périphériques affichés dans la Figure 7-1 sont listés ici.
/pci@1f,4000/usb@5/storage@1
/pci@1f,4000/usb@5/hub@2/device@1/keyboard@0
/pci@1f,4000/usb@5/hub@2/device@1/mouse@1
/pci@1f,4000/usb@5/hub@2/storage@3
/pci@1f,4000/usb@5/hub@3/printer@1
Les périphériques USB avec des attributs et des services similaires sont regroupés dans des classes de périphériques. A chaque classe de périphérique correspond un pilote. Les périphériques d'une même classe sont gérés par la même paire de pilote-périphérique. Toutefois, la spécification USB autorise également les périphériques propres à un fournisseur ne faisant pas partie d'une classe spécifique.
La classe Périphérique d'interface homme-machine (HID) contient des périphériques contrôlés par l'utilisateur, comme les périphériques suivants :
Claviers
Souris
Manettes de jeu
La classe Périphérique de communication comprend les périphériques suivants :
Modems
Adaptateurs Ethernet
Les autres classes de périphériques sont notamment :
Audio
Moniteur
Imprimante
Périphérique de stockage
Chaque périphérique USB contient des descripteurs qui reflètent la classe du dispositif. Une classe de périphérique indique la manière dont ses membres doivent se comporter lors de la configuration et du transfert de données. Pour plus d'informations sur les classes, consultez le site Web à l'adresse suivante :
Pour plus d'informations sur les périphériques USB pris en charge dans cette version d'Oracle Solaris, reportez-vous à usb(7D).
Les améliorations apportées au pilote USB suivantes sont incluses dans cette version d'Oracle Solaris.
Prise en charge des périphériques USB CDC ACM : le pilote acm peut fonctionner avec des périphériques conformes au modèle de contrôle abstrait de la spécification sur la classe de périphériques de communication USB, ainsi qu'avec certaines cartes PCMCIA qui ont des capacités de modem.
Le démon pppd peut accéder à ces périphériques par l'intermédiaire des entrées /dev/term/[0~9]*. Pour plus d'informations, reportez-vous à pppd(1M).
Pour plus d'informations, reportez-vous à usbsacm(7D).
Pilote USB générique : les applications peuvent à présent accéder aux périphériques USB et les manipuler grâce aux appels système UNIX read(2) et write(2) standard, et sans écrire de pilote de noyau particulier. Les fonctions supplémentaires sont notamment :
Accès des applications aux données brutes et à l'état des périphériques.
Prise en charge par le pilote des transferts de contrôle, par lot et avec interruption (entrée et sortie).
Le pilote ugen n'a plus besoin de se lier explicitement à un périphérique. Par défaut, usb_mid se lie aux périphériques qui ne disposent pas d'un pilote de classe et exporte une interface ugen qui fonctionne avec libusb. Par exemple, vous pouvez brancher un appareil photo USB qui n'est pas un périphérique de stockage et utiliser une application libusb pour y accéder. De plus, les deux pilotes scsa2usb et usbprn exportent les interfaces ugen et les applications libusb peuvent être utilisées directement sur ces classes de périphériques.
Pour plus d'informations, reportez-vous à ugen(7D).
Prise en charge du pilote USB série
Prise en charge de Digi Edgeport USB : le pilote Edgeport USB fonctionne uniquement avec les périphériques Edgeport et avec aucun autre périphériques USB série.
Les nouveaux périphériques sont accessibles en tant que /dev/term/[0-9]* et /dev/cua/[0-9]*.
Les ports série USB sont utilisables comme tout autre type de port série, si ce n'est qu'ils ne peuvent pas servir de console série locale. Le fait que leurs données soient exécutées à travers un port USB est transparent pour l'utilisateur.
Pour plus d'informations, reportez-vous à la rubrique usbser_edge(7D), ou consultez les sites Web suivants :
Keyspan : le pilote série USB Keyspan fonctionne uniquement avec les périphériques Keyspan et prend actuellement en charge les modèles USA-19HS et USA-49WLC.
Pour plus d'informations, reportez-vous à usbsksp(7D).
Prolific : le pilote série USB Prolific fonctionne uniquement avec les périphériques basés sur le chipset PL2303.
Pour plus d'informations, reportez-vous à usbsprl(7D).
Pour plus d'informations sur la prise en charge USB vers périphériques série, consultez le site Web à l'adresse suivante :
Documentation et prise en charge des binaires pour les pilotes de noyau et userland écrits par l'utilisateur : pour des informations à jour sur le développement de pilote USB, consultez les documents suivants :
Fonctions du pilote EHCI :
Compatibilité avec l'interface de contrôleur hôte améliorée, qui prend en charge USB 2.0.
Prise en charge des transferts de contrôle, par lot, avec interruption et isochrones haut débit.
La puce USB 2.0 comporte un contrôleur EHCI et au moins un contrôleur OHCI ou UHCI.
Un périphérique USB 1.1 est assigné de manière dynamique au contrôleur UHCI ou OHCI lorsqu'il est connecté. Un périphérique USB 2.0 est assigné de manière dynamique au contrôleur EHCI lorsqu'il est connecté.
Utilisez le résultat de la commande prtconf pour savoir si votre système prend en charge les périphériques USB 1.1 ou USB 2.0. Par exemple :
# prtconf -D | egrep "ehci|ohci|uhci"
Si le résultat de la commande prtconf identifie un contrôleur EHCI, votre système prend en charge les périphériques USB 2.0.
Si le résultat de la commande prtconf identifie un contrôleur OHCI ou UHCI, votre système prend en charge les périphériques USB 1.1.
Les périphériques USB peuvent être représentés sous la forme de deux niveaux de noeuds d'arborescence des périphériques. Un noeud de périphérique USB représente l'ensemble du périphérique USB. Un ou plusieurs noeuds d'interface enfant représentent les interfaces USB du périphérique.
La liaison du pilote est obtenue en utilisant les propriétés de nom compatibles. Pour plus d'informations, reportez-vous à la section 3.2.2.1 de l'IEEE 1275 USB binding et à Writing Device Drivers. Un pilote peut soit établir une liaison vers le périphérique complet et contrôler toutes les interfaces, soit établir une liaison vers une seule interface. Si aucun pilote fournisseur ou de classe ne revendique le périphérique complet, un pilote USB générique multi-interface établit une liaison vers le noeud au niveau du périphérique. Ce pilote tente de lier les pilotes à chaque interface en utilisant les propriétés de nom compatibles, tel que défini dans la section 3.3.2.1 de l'IEEE 1275 Binding specification.
L'architecture Oracle Solaris SUB (USBA) est conforme aux spécifications USB 1.1 et USB 2.0, et fait partie de l'interface de pilote de périphériques (DDI) d'Oracle Solaris. Le modèle USBA est semblable à l'architecture d'Oracle Common SCSI (SCSA). Comme l'illustre la figure suivante, l'USBA est une couche fine qui fournit une abstraction de la couche de transport USB générique aux pilotes de client, leur fournissant des services qui implémentent une fonctionnalité USB générique fondamentale.
Figure 7-2 Architecture Oracle Solaris USB (USBA)