Salut !!
[man-histoire]
J'ai remarqué que l'USB est pas mal fait : chaque constructeur se voit offrir (pour une modique somme j'immagine) un numéreau unique (Vendor_Id) fourni par www.usb.org.
Jusque là, tout va bien dans le meilleur des mondes, les dév. de drivers n'ont qu'à récupérer la liste sur le site, avec les noms des constructeurs qui vont bien.
Mais des petits malins créent du matériel USB avec des spécifs bizarre (Vendor_ID=0x123 par ex.) qui n'existent bien sûre pas dans la base. Tout ça pour que WinTruc n'affiche pas : c'est un serial-usb donc je crée un port serie virtuel, etc. Ils peuvent créer leur driver avec une belle interface qui dit : installation du driver truc pour le matériel machin...
Mais sous Linux, pas de driver.
[/man-histoire]
Ma question qui vous fait tant languire est : peut-on forcer un driver Linux à utiliser un périphérique ayant un product-id différent ? et Si oui : comment ?
sinon, faut-il le rajouter dans le source et recompiler ?
Merciiiiiiiiiiiii !!!
Dav'
Journal USB et les constructeurs
3
nov.
2003
# Re: USB et les constructeurs
Posté par gnumdk (site web personnel) . Évalué à 2.
pour le reste, je sais pas :)
[^] # Re: USB et les constructeurs
Posté par Cyberdivad . Évalué à 1.
Ca serait cool, car je pourrais enfin me passer de la ligne commande de gphoto (avec lequel j'utilise cette astuce pour faire reconnaitre mon appareil), que je ne trouve pas pratique, ou alors je l'utilise mal (comment transférer toutes les photos se trouvant dans l'appareil en un bloc par exemple).
# Re: USB et les constructeurs
Posté par account . Évalué à 1.
devrait faire l'affaire, non ?
# Re: USB et les constructeurs
Posté par Gruik Man . Évalué à 7.
1500$
En fait, pas vraiment. Pour les drivers « génériques » (utilisant des "classes" d'interfaces définies dans la spécification, comme Human Input Device, Mass Storage, Communication, etc), le Vendor ID et le Product ID ne sont pas pris en compte: seul sont pris en compte la classe du périphérique, et le descripteur de celui-ci (lequel descripteur indique, par exemple, « ce périphérique d'interface homme-machine a 105 touches de clavier, celui-ci a deux pointeurs de position et 3 boutons », etc.). Ainsi, un clavier USB, ou une clé de stockage de données, seront toujours reconnus par le système, même s'ils annoncent un Vendor ID farfelu, _à condition_ qu'ils se décrivent en tant que tels.
Maintenant, effectivement, rien n'empêche un constructeur de développer un périphérique utilisant une classe « Vendor » alors qu'il pourrait utiliser une classe standard, _ou bien_ utiliser une classe standard mais avec un descripteur exotique (le système ne saura pas quoi faire de ce simulateur de tapis volant équipé de 105 molettes fournissant des données en kilojoules). Possible, mais stupide: dans le cas 1, il devra développer un driver (et ça coûte cher, en temps et en argent; sans compter qu'il devra en développer et en maintenir -- voire en faire signer -- un par système supporté), dans le cas 2, il pourra s'en sortir avec une application en userland, ça coûte moins cher, mais quand même un peu. Le fabricant de produits USB a tout intérêt, tant que faire se peut (ce n'est pas toujours possible), à utiliser les drivers génériques, déjà codés.
Maintenant, des gens stupides, il y en a légion, hélas, et sans doute que certains ont eu recours à de tels procédés pour avoir à développer leurs propres drivers. Mais ce n'est pas toujours de la stupidité: certains périphériques ne peuvent pas s'intégrer dans une classe de périphériques, ou offrent des fonctionnalités, décrites de manière standard, mais inconnues des drivers génériques (un driver générique conçu pour les souris, par exemple, ne comprendra pas forcément ce qu'il doit faire des informations « pression » ou « orientation » fournies par une tablette graphique (qui se décrit pourtant conformément au standard), même s'il est capable de déplacer le pointeur lorsque le stylet se déplace)
Dans le cas qui te concerne (ou qui semble te concerner, tu n'as pas été très précis en ce qui concerne ton matériel), tu sembles regretter que ton convertisseur USB-port série ne fonctionne qu'avec des drivers « fabricant », et pas des drivers génériques. Je m'abuse peut-être, mais je ne pense pas qu'une classe USB soit définie qui supporte ce type de matériels (donc, pas de driver générique). Dans ce cas, le système peut très bien avoir une base de données de drivers pour les périphériques usb<->serial les plus courants (c'est le cas sous Linux et sans doute sous Windows), mais un fabricant de périphériques moins connu n'aura pas les périphériques dans la base. Ce n'est pas de la malveillance s'il utilise un Vendor ID inconnu: il utilise juste _le sien_! Il n'a pas vraiment le droit d'utiliser un Vendor ID qui appartient à quelqu'un d'autre.
Pour (enfin) répondre à ta question: le driver usb-serial de Linux permet, effectivement, d'essayer d'utiliser un périphérique qu'il ne connaît pas, en spécifiant le Vendor ID et le Product ID dudit périphérique, et en lui disant « ça, c'est un convertisseur USB-serie, je le sais, débrouille-toi pour le faire marcher ». Il utilise, d'après ce que j'ai compris, une méthode assez bourrine, mais qui, paraît-il, marche parfois: si il trouve un canal de données de type « Bulk » montant, et un descendant, il s'en sert de l'un pour envoyer, et de l'autre pour recevoir. Un périphérique usb<->série logiquement conçu, effectivement, devrait faire passer les données de cette manière (et utiliser un canal différent, de type interrupt, pour les messages de contrôle).
Je cite la doc du driver usb-serial:
Tu peux essayer ça, ça pourra peut-être marcher
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.