Hi,
Ich habe ein USB Gerät mit funktionierendem Report/Kommunikation.
Da der Report mehrere Controller enhält, die in der Gamepad-Anzeige im
Betriebssystem alle den gleichen Namen haben, wollte ich versuchen, den
Controllern String Indices hinzuzufügen.
Ich habe die HID Usage Tables 1.12 spec vor mir und versuche die Sache
mit den Strings zu verstehen. Ich werde aus dem Beispiel "A.14 Graphic
Equalizer" nicht schlau. Die Tabelle 23 ergibt für mich keinen Sinn.
insbesondere die letzten beiden Felder der Typspalte.
Auch was Kapitel 3.6 HID LANGIDs mir sagen will, verstehe ich nicht.
Muss noch irgenwas zusätzliches gemacht werden, um HID Strings zu
benutzen?
Die Normalen USB-String-Descriptoren sind kein Problem. Dem
HID-Report-Descriptor kann man auch "String Index", "String Minimum",
"String Maximum" Kommandos hinzufügen.
Wenn ich in die Firmware einfach neue String-Descriptoren einbaue und in
den Report entsprechenden Indices, wird das Gerät nicht mehr erkannt.
Ich weiß nicht, ob die Strings vielleicht nur auf bestimmten
Ebenen/Elementen gültig sind, oder ich was anderes falsch mache.
Ich habe mehrere Reports, wie diesen und würde diesen gerne eigene Namen
geben.
(Am liebsten auch den Buttons)
Im Report Descriptor haben Strings auch nichts zu suchen. Der beschreibt
das Datenformat, in dem das Gerät seine Eingabedaten sendet, bzw.
Ausgabedaten haben möchte.
Wenn sich das Gerät mit einem anderen Namen identifizieren soll, dann
musst Du in den Device Desciptor gucken, auf welchen String der als
Product String verweist und den dann ändern. Neue Strings hinzu fügen
dürfte eher in die Hose gehen.
Falls das Gerät aber mehr als ein Interface definiert, zeigt Windows
nicht den Device String an, sondern den Interface String des jeweiligen
Interfaces. Die kann man natürlich auch ändern.
Falls keine Interface Strings definiert sind (die sind optional), dann
wäre erst mal heraus zu finden, ob einfach so weitere hinzu gefügt
werden können. Ich habe da schon beliebig schlechte Implementierungen
gesehen…
@theBug:
du hast meinen Beitrag scheinbar nicht gelesen.
Ich habe ein HID Interface und einen Reportdescriptor, der 4 Reports
definiert (ID 1-4).
Diese 4 Geräte zeigt windows in der Gamepadübersicht alle mit gleichen
Namen an.
Die HID-Specification erlaubt sehr wohl die Zuordnung eigener
Zeichenketten zu Kontrollelementen. Die Fragen sind nur, 1. genau wie
und 2. kann ich den ReportIds (einzelnen Controllern) auch Strings
zuweisen.
Du hast anscheined nicht gelesen, was ich geschrieben habe…
…sind nur >20 Jahre Erfahrung mit USB bei mir…
Die USB-Spec hat einige tolle Sachen drin, die in keinem einzigen
Betriebssystem implementiert sind. Windows ist besonders Kacke darin USB
sauber umzusetzen.
Wenn Du willst, dass die einzelnen Funktionen mit Namen angezeigt
werden, dann gibst Du den Interfaces Namen. Was anderes geht unter
Windows nicht.
Vlad T. schrieb:> Diese 4 Geräte zeigt windows in der Gamepadübersicht alle mit gleichen> Namen an.
Schau mal nach ob der Name irgendwo in einer .inf Datei steht...
Vlad T. schrieb:> Die HID-Specification erlaubt sehr wohl die Zuordnung eigener> Zeichenketten zu Kontrollelementen.
Das heisst noch lange nicht dass das auch der der Windows HID Treiber
unterstützt. Windows nimmt Gerätenamen normalerweise aus .inf Dateien,
nur ganz selten werden USB Hardware Strings angezeigt. Hat auch was mit
Lokalisierung zu tun.
Vlad T. schrieb:> Wenn ich in die Firmware einfach neue String-Descriptoren einbaue und in> den Report entsprechenden Indices, wird das Gerät nicht mehr erkannt.
Welcher Fehlercode kommt, was steht in der Ereignisanzeige?
Jim M. schrieb:> Vlad T. schrieb:>> Diese 4 Geräte zeigt windows in der Gamepadübersicht alle mit gleichen>> Namen an.>> Schau mal nach ob der Name irgendwo in einer .inf Datei steht...
Gibt keine .inf-Datei
Das Gerät funktioniert (abgesehen von den betriebssystemeigenen)
komplett treiberlos. Es übermittelt alle Namen per String-Descriptoren.
Hier hab ich aber noch einen Bug in der String-Descriptor-Behandlung
gefunden - muss erst mal testen, ob es daran gelegen haben könnte.
Jim M. schrieb:> Welcher Fehlercode kommt, was steht in der Ereignisanzeige?
muss ich nachschauen, sollte das unter "System" kommen?
TheBug schrieb:> Du hast anscheined nicht gelesen, was ich geschrieben habe…> …sind nur >20 Jahre Erfahrung mit USB bei mir…
Das ist super. Kannst du mir vielleicht erklären, wie das mit den
LANGIDs und den HID LANGIDs funktionieren sollte und ob bei der
Behandlung der Descriptor-Requests im Falle von HID irgend was
Besonderes zu tun ist.
Ich glaube meinem Verständnis wäre es sehr geholfen, wenn ich für das
Graphic Equalizer Beispiel aus der hid usage table spec sehen würde, wie
die String-Descriptor-Request-Behandlung aussehen würde. Und wie der
Datenblock aussehen müsste (und vielleicht wie der String-0-Descriptor
aussehen müsste.
Der String 0 Descriptor gibt nur an was die Primärsprache für das Device
ist, ggf. kann man noch mehr LangIDs anhängen. Was und ob überhaupt das
System damit macht ist aber durchaus nicht sicher, hängt von der
Plattform ab.
Das Graphic Equalizer Beispiel ist wohl eines der gestrandeten
Beispiele.
Wie gesagt, es ist in USB sehr viel definiert, was auch richtig prima
wäre. Beispielsweise die Simulation Controls. Damit könnte man quasi die
Elemente z.B. von einem Flugzeugcockpit bauen und die identifizieren
sich alle selber.
Hat Microsoft dann nie unterstützt, die Spielehersteller auch nicht.
Damit ist das leider nie eingesetzt worden.
Die meisten Device-Entwickler haben das schon vor Jahren aufgegeben. Es
macht halt keinen Sinn ein Device nach den Details des Standards zu
abuen, die keine Sau unterstützt.
Vlad T. schrieb:> Jim M. schrieb:>> Welcher Fehlercode kommt, was steht in der Ereignisanzeige?> muss ich nachschauen, sollte das unter "System" kommen?
Das bei dem Gerät mit dem dicken fetten gelben Ausrufezeichen kommen.
Steht da keins, funktioniert das Gerät (von Windows aus gesehen).
Vlad T. schrieb:> Gibt keine .inf-Datei
Blödsinn!
Windows liefert eine metrische Tonne inf Dateien mit. Suche mal in
c:\Windows\inf nach dem Namen der im Gerätemanager auftaucht.
Allerdings scheint die deutsche Übersetzung nur im zugerörigen *.PNF zu
stehen (in UTF-16).
TheBug schrieb:> Der String 0 Descriptor gibt nur an was die Primärsprache für das Device> ist, ggf. kann man noch mehr LangIDs anhängen. Was und ob überhaupt das> System damit macht ist aber durchaus nicht sicher, hängt von der> Plattform ab.
Ja und in der spec steht da, dass außerdem ein HID LANGID dieser Liste
hinzugefügt werden muss
Mir ist halt an der stelle das zusammenspiel nicht wirklich klar, was
muss wo definiert werden und wie müssen die descriptoren genau aufgebaut
sein.
Ich komme erst morgen abend dazu. vielleicht reicht ja schon das Beheben
des offensichtlichen Bugs, den ich in der
String-Descriptor-Requetbehandlung gefunden habe.
TheBug schrieb:> Wie gesagt, es ist in USB sehr viel definiert, was auch richtig prima> wäre. Beispielsweise die Simulation Controls. Damit könnte man quasi die> Elemente z.B. von einem Flugzeugcockpit bauen und die identifizieren> sich alle selber.
Das hängt ja auch von der Software ab, die explizit dannach fragen kann.
klar kann windows nicht alles unterstützen, aber throttle zB kann es.
Jim M. schrieb:> Vlad T. schrieb:>> Gibt keine .inf-Datei>> Blödsinn!>> Windows liefert eine metrische Tonne inf Dateien mit. Suche mal in> c:\Windows\inf nach dem Namen der im Gerätemanager auftaucht.
Zu dem gerät gibt es mit sicherheit keine, da das ein Selbstbau ist.
Hier kommen nur die generisschen HID-Treiber zu Tragen. Im Gerätemanager
steht natürlich der generische Name. Die
Gamecontroller-Eingeschaftenseite zeigt aber die Strings aus der
Firmware an.
Jim M. schrieb:> Blödsinn!>> Windows liefert eine metrische Tonne inf Dateien mit. Suche mal in> c:\Windows\inf nach dem Namen der im Gerätemanager auftaucht.
Ja klar, Microsoft schafft es auch immer auf magische Weise ein neues
.inf File auf meinem Rechner materialisieren zu lassen, sobald ich einen
neuen Prototypen anschließe, den noch niemand sonst gesehen hat…
m)
USB Geräte funktionieren auch ohne diesen .inf Schwachsinn.
Praktischerweise ist der Standard so ausgelegt, dass sich die meisten
Geräte mittels Descriptoren korrekt beschreiben lassen, so dass sie von
generischen Treibern bedient werden könne.