Journal USB et les constructeurs

Posté par  (site Web personnel) .
Étiquettes : aucune
0
3
nov.
2003
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'
  • # Re: USB et les constructeurs

    Posté par  (site Web personnel) . Évalué à 2.

    pour les appareils photo usb, gphoto permet de spécifier le Product_ID.

    pour le reste, je sais pas :)
    • [^] # Re: USB et les constructeurs

      Posté par  . Évalué à 1.

      Tiens, ca m'amène à une question : est-il possible de faire en sorte de faire la même manip, mais par GTkam (qui utilise gphoto2 je crois) ?

      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  . Évalué à 1.

    modprobe module product=0x123 vendor=0x456
    devrait faire l'affaire, non ?
  • # Re: USB et les constructeurs

    Posté par  . Évalué à 7.

    J'ai remarqué que l'USB est pas mal fait : chaque constructeur se voit offrir (pour une modique somme j'immagine)


    1500$

    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...


    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:

    If your device is not one of the above listed devices, compatible with
    the above models, you can try out the "generic" interface. This
    interface does not provide any type of control messages sent to the
    device, and does not support any kind of device flow control. All that
    is required of your device is that it has at least one bulk in endpoint,
    or one bulk out endpoint.

    To enable the generic driver to recognize your device, build the driver
    as a module and load it by the following invocation:
    insmod usbserial vendor=0x#### product=0x####
    where the #### is replaced with the hex representation of your device's
    vendor id and product id.


    Tu peux essayer ça, ça pourra peut-être marcher

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.