Re: USB PIDs zu verkaufen

Michael Eggert <m.eggert.nul@xxxxxx> schrieb:

Ich sehe nur, daß einige grundverschiedene Devices alle mit der
gleichen VID/PID daherkommen, weil sie nunmal alle auf AVR-USB von
obdev beruhen.

Dieses Vorgehen ist natürlich nicht im (ursprünglichen) Sinne von USB.
Da sollten verschiedene "functions" verschiedener Hersteller sehr wohl
getrennte VID/PID-Paare bekommen, damit man sie an Hand dieser auch
auseinander halten kann.

Dass es zu derartigen Verrenkungen kommt, hat sich die USB-Allianz
dann allerdings auch selbst zuzuschreiben, womit wir wieder zurück
beim Ausgangspunkt dieses Threads sind: wenn sie schon für die
Herausgabe einer VID eine ,,Bearbeitungsgebühr'' von USD 2000
verlangen (nein, verkaufen tun sie die ja nicht), /und/ dann auch noch
dem Antragsteller strikt verbieten (siehe VOTI), dass er diese
gewissermaßen scheibchenweise preiswerter weiterreichen kann (was ja
überhaupt erst einmal ermöglicht hätte, dass auch Klein- und
Hobbyanwender sich wirklich ein VID/PID-Paar leisten können), dann
verwundert es auch nicht, dass am Ende die Leute entweder VID/PIDs
erfinden oder aber x-fach für völlig unterschiedliche Dinge nutzen.

Weiterhin sehe ich, daß wenn ich ein neues Device
erstmals anstecke, irgendwas schiefläuft: Entweder Windows kennt diese
VID/PID schon an dem Port, dann erscheint das neue Device mit dem
Namen des alten im Gerätemanager. Oder Windows kennt die VID/PID noch
nicht an diesem Port, dann installiert es den Treiber neu und ab jetzt
trägt das alte Device den Namen des neuen.

Da kommt bei Windows noch dazu, dass es keinen generischen USB-Treiber
kennt. Man /muss/ ein Gerät also explizit mit einem bestimmten
Treiber registrieren, ein Fallback auf einen allgemeinen Treiber ist
nicht vorgesehen. Die Unixe (zumindest die Opensource-Unixe, unter
Solaris habe ich nie wirklich mit USB gearbeitet bislang) haben
dagegen generische Treiber, die entweder als Fallback benutzbar sind,
wenn kein Treiber gefunden wurde (ugen-Treiber bei NetBSD/FreeBSD)
oder aber fest eingebaut, gewissermaßen unterhalb eines Vendor- oder
Class-Treibers (Linux), auf denen die libusb aufsetzen kann. Dadurch
bedarf es dort keines Eintrages in irgendwelche Gerätemanager, eine
interessierte Applikation kann einfach alle USBusse scannen, bis sie
das gewünschte Gerät an Hand selbst festgelegter Kriterien (also
entweder nur VID/PID plus ggf. Seriennummer, oder vendor/product
string oder was auch immer) gefunden hat. In diesem Falle wird also
einfach der Entscheidungprozess vom Betriebssystem an die Applikation
selbst delegiert.

[AVRDUDE]

(Der Name wird allerdings dort nicht
ausgewertet, es wird davon ausgegangen, dass jeder, der mit den
passenden Atmel VID/PID-Paaren daher kommt, sich dann auch wie das
entsprechende Gerät benimmt.)

Tja, nur kann man wohl nicht immer davon ausgehen... und zumindest im
Fall von USBasp dürfte dann auch AVRDUDE drauf reinfallen und sich
munter mit der uDMX- oder Powerswitch-Hardware unterhalten.

Nein, der entsprechende AVRDUDE-Code für USBasp stammt ja von obdev.at
selbst, und der kümmert sich sehr wohl um vendor und product string.
Der Code sieht sehr ähnlich aus wie das, was du gepostet hast. Ich
vermute mal, dass das einfach ohnehin Beispielcode von obdev.at ist,
um mittels libusb auf ihren Stack zuzugreifen.

Meine Beschreibung bezog sich auf den Zugriff für die Atmel-eigenen
Tools.

Trotzdem funktionierts nicht, wenn Windows den uDMX gerade als
USBasp erkannt hat. Ob es nun daran liegt, daß die Abfrage der
Strings überhaupt nicht bis zum Device durchdringen sondern Windows
oder was auch immer einfach das zurückliefert, was es unter dieser
VID/PID zu kennen meint - keine Ahnung. Ich hab nur gesehen, _daß_
es nicht funktioniert.

Das kann natürlich wirklich an besagten Verrenkungen liegen, die
libusb-win32 machen muss, um das API umzusetzen. Wäre ggf. aber mal
ein Debugging wert. Ah, wart mal, lass mich raten: obdev.at bringt
doch einen eigenen vendor-Treiber mit für den Zugriff mittels libusb,
oder? Wenn das Gerät nun von Windows einem anderen Treiber zusortiert
worden ist (weil die Treiberzuordnung ja nur auf VID/PID-Basis oder
Klassenbasis erfolgt), dann hat die libusb danach keinen Haken mehr,
mit dem sie zugreifen kann.

Dagegen könnte es aber helfen, wenn du zusätzlich noch von
libusb-win32 den Filtertreiber installierst. Der benutzt (soweit ich
das verstehe) Hooks, die allgemein im USB-API schon drin sind und
unterhalb jedes Treibers liegen. In diesem Falle müsste die libusb
auch wieder Zugriff bekommen können, wenn Windows das Gerät deinem
uDMX-Treiber zugewiesen hat. (Wenn Windows einen generischen Treiber
für unbekannte USB-Geräte hätte, dann wäre der Filtertreiber
eigentlich das Einzige, was die libusb-win32 bräuchte, um Zugriff auf
beliebige USB-Geräte zu erlangen.)

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
.

Relevant Pages

  • =?ISO-8859-15?Q?Re:_=F6ffnet_outlook_schon_beim_klick_die_mail=3F?=
    ... Generell sind die integrierten Treiber und Applikationen schon bei ... > 3rd Party weil Windows die Karte erstmal garnicht kennen will. ... >> Das SP2 ist KEIN Patch oder Hotfix. ... kostenlosen Support durch MSFT in Anspruch nehmen. ...
    (de.comp.security.misc)
  • =?ISO-8859-15?Q?Re:_=F6ffnet_outlook_schon_beim_klick_die_mail=3F?=
    ... was wieder mehr Probleme als die saubere Neuinstallation bringt. ... > wieder auf das Treiber gerne Systemdateien von Windows überschreiben. ... das Windows ME/2000/XP/... ... >> Sicherheit getan hat. ...
    (de.comp.security.misc)
  • Re: Sind Treiberinstallationen noetig?
    ... Für Windows brachte es eine CD mit Treibern und allem Möglichen ... Trotzdem lief es auch unter Linux, ... Windows hat natuerlich einen generischen Treiber fuer AT-kompatible ... Terminal-Programm starten, und AT-Kommandos absetzen. ...
    (de.comp.security.misc)
  • Re: =?ISO-8859-15?Q?=F6ffnet?= outlook schon beim klick die mail?
    ... Wenn man den manipulierenden Treiber wieder deinstalliert wohl schon, ... wollen die Hersteller nicht darauf verzichten:( ... > gibt's Windows 2000. ... Erstinstallation wieder aktiv. ...
    (de.comp.security.misc)
  • Re: USB PIDs zu verkaufen
    ... VID/PID schon an dem Port, dann erscheint das neue Device mit dem ... Oder Windows kennt die VID/PID noch ... munter mit der uDMX- oder Powerswitch-Hardware unterhalten. ...
    (de.sci.electronics)
Loading