WinUSB *.inf unter x64

[Mox]

Achromat schrieb:

in der Doku steht das lediglich das erste Byte noch beachtet wird. Das trifft nun aber für SetFuture zu.

Das gilt selbstverständlich auch für HidD_SetOutputReport und HidD_GetInputReport und steht auch in der Doku, man muss sie nur lesen:

MSDN schrieb:

If the top-level collection includes report IDs, the caller must set the first byte of the ReportBuffer parameter to a nonzero report ID.

If the top-level collection does not include report IDs, the caller must set the first byte of the ReportBuffer parameter to zero.

Achromat schrieb:

Das es sich um ein Equalent zum HID_Input oder zum HID_SetFurute verhält ist ja doll..

Nochmal, nur für Dich: ReadFile/HidD_GetInputReport sind ebenso wie WriteFile/HidD_SetOutputReport das Gleiche. Und da sie das Gleiche machen, sind auch die Puffer identisch zu initialisieren. Allerdings suchen sich ReadFile/WriteFile den effizientesten Weg und nehmen die zugeordneten Endpunkte. Erst wenn es keine zugeordneten Endpunkte gibt, geht es über EP0. Die Funktionen HidD_GetInputReport und HidD_SetOutputReport nehmen immer den langsamen Weg über EP0.

Für Feature-Reports gibt es keine zugeordneten Endpunkte. Das muss es auch nicht. Es geht ja schließlich nur um die Geräte-Features, bzw. die Geräte-Konfiguration. Von daher kann hier immer der langsame Weg über EP0 genommen werden. Und genau deswegen gibt es hier auch kein "Equalent", wie Du so schön sagtest.

So, wie Du momentan kommunizierst, erzeugst Du unnötig Buslast. Wieso? Wieso machst Du es nicht einfach richtig?

Achromat schrieb:

Und genau dann wird auch wieder das geformtes WINUSB Request verwendbar (unter HId_Write statt HID_SetFuture(Vermutung).

Ich verstehe nicht ganz. Du hast Dich jetzt für HID entschieden. Da wirst Du keine WINUSB Requests los.

Achromat schrieb:

Natürlich wenn der dritte Endpunkt auch wirklich off sein sollte.

Ein HID hat neben dem EP0 maximal zwei Endpunkte, nicht drei.