Satyria: Die Seite wurde neu angelegt: „Informationen: usbconfigparser.c: Wichtig hier zu wissen: Warum wird hier "Audio" erwähnt? Bei Audio-Geräten, wie USB-Headset gibt es im USB-Standard eine Besonderheit: Ein normaler Endpoint-Deskriptor (DESCRIPTOR_ENDPOINT) hat eine feste Länge von 9 Bytes (sizeof(TUSBEndpointDescriptor)). Bei USB Audio Class 1.0 Geräten enthält der Endpoint-Deskriptor jedoch zusätzliche Audiodaten (z.B. für Synchronisation oder Refresh-Raten) und ist daher 11 Byt…“

2026-07-17T05:36:41Z

Die Seite wurde neu angelegt: „Informationen: usbconfigparser.c: Wichtig hier zu wissen: Warum wird hier "Audio" erwähnt? Bei Audio-Geräten, wie USB-Headset gibt es im USB-Standard eine Besonderheit: Ein normaler Endpoint-Deskriptor (DESCRIPTOR_ENDPOINT) hat eine feste Länge von 9 Bytes (sizeof(TUSBEndpointDescriptor)). Bei USB Audio Class 1.0 Geräten enthält der Endpoint-Deskriptor jedoch zusätzliche Audiodaten (z.B. für Synchronisation oder Refresh-Raten) und ist daher 11 Byt…“

Neue Seite

Informationen:

usbconfigparser.c:
Wichtig hier zu wissen:
Warum wird hier "Audio" erwähnt?
Bei Audio-Geräten, wie USB-Headset gibt es im USB-Standard eine Besonderheit:
Ein normaler Endpoint-Deskriptor (DESCRIPTOR_ENDPOINT) hat eine feste Länge von 9 Bytes (sizeof(TUSBEndpointDescriptor)).
Bei USB Audio Class 1.0 Geräten enthält der Endpoint-Deskriptor jedoch zusätzliche Audiodaten (z.B. für Synchronisation
oder Refresh-Raten) und ist daher 11 Bytes groß.

Wenn der Parser auf ein Interface stößt, das zur USB-Audioklasse gehört:

bInAudio10Interface = pCurrentPosition->Interface.bInterfaceClass == 0x01
&& pCurrentPosition->Interface.bInterfaceProtocol != 0x20;

...merkt er sich das über die Flag bInAudio10Interface.
Sobald er danach den dazugehörigen Endpoint-Deskriptor analysiert:

if (bInAudio10Interface)
{
// Audio class 1.0 EP descriptors have additional fields.
ucAlternateLen = sizeof (TUSBAudioEndpointDescriptor);
}

...erlaubt er als alternative, gültige Länge auch die 11 Bytes der Audio-Spezifikation. Ohne diese Unterscheidung
würde der Parser den Deskriptor fälschlicherweise als fehlerhaft (beschädigt) einstufen und das Gerät ablehnen.

Warum ist das hier wichtig:
Sicherheit vor Abstürzen: Sollte ein Benutzer jemals versehentlich ein USB-Headset oder ein USB-Mikrofon in den
Raspberry Pi stecken, sorgt dieser Code dafür, dass der USB-Stack das Gerät sauber als „nicht unterstützt“ ignoriert.
Sollte dies fehlen, würde der Parser bei einem solchen Gerät einen Invalid Configuration Descriptor-Fehler werfen und
den gesamten USB-Port oder -Stack blockieren.

USB (PI4) - Versionsgeschichte