From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by mx.groups.io with SMTP id smtpd.web10.13449.1625250176235232096 for ; Fri, 02 Jul 2021 11:22:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MwevwmfR; spf=pass (domain: gmail.com, ip: 209.85.218.54, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f54.google.com with SMTP id c17so17494629ejk.13 for ; Fri, 02 Jul 2021 11:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=XjgYupuVnd0/PmBDlSotAys7llrw7LlpnAARMJlCQy8=; b=MwevwmfRQYO2+tdpAsjjQs89BkOiZ1KdIRk6qirfB0NuGiYcP4IWu2KLwNGnCzdc/5 RwDRsXT6BVsRDovFhe83XuJkVkU480zXdWljj+PkXAvApi/Bo/kCEg2gghvGLDsb6I1E k+SNufXe1DXMb8bLdbmtcnC13YLbs3PVLjqiSfgXobRt2gjU8EEUezUYTM3zpVxFsvfy vuVJMPyEd4OisWeoIL3jg9qTVZzv4z2qnDAqqmM8hoNhifi3nIWP3yhQ+ltHPn+HKNH7 j1gGsHQu1VpI+ua0N8MGahLcXcYTFJPqDT1Lhx4dwiw+Kjp8aGEormv4L5SyA8dWOyyS gt0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=XjgYupuVnd0/PmBDlSotAys7llrw7LlpnAARMJlCQy8=; b=KtPKlN9DwD7wQhREUFot7fKY+rOnus8+y3YrDew72FGh+XFKy8DDqd2RW8D61u2MgH Gy1wdb1y1tPL5pkjJePGdkDg0GPaEH7Jr59GZVijZXxe66zBcAC1v3Yj3v16xVuOygOV Yg8pRYL9P0VMio6UPNquJDLfo7BPe5I/LZRoFZiRPGcx4nNH4c8lsZ9J6yK/maqj4Utm 9l4D3Z5AHyDXr/Iwlwh9UtALJrBpbgmZMAIqZCt/L6pO0QivSx3rdzFdpve2sBfNBxIu 9udhbESAl1DJBeVwoX9ohrBmVlDPPfOemIREEfxMby7MYkSYKYxuF7lDzn+Qba9jfevG jFwA== X-Gm-Message-State: AOAM5331PZCa2BXrRSwhxJbFioH4BXSmJ8iP+v9+B8ZXa6qJdJx0tREs EVzjYjikQutPwEDOHJ+wkqFUdUjdNRJN8G1z3oL3pIou X-Google-Smtp-Source: ABdhPJx4mXL63bIU+6C0FaEeLwlobWwe2KjkrT6moGc2DugTgGhgGwsgrIknXSZHOZnuNf4C5Rp8jLz/23A7lQtpmjE= X-Received: by 2002:a17:906:1c5b:: with SMTP id l27mr1131993ejg.40.1625250174697; Fri, 02 Jul 2021 11:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6400:5b92:0:0:0:0 with HTTP; Fri, 2 Jul 2021 11:22:54 -0700 (PDT) In-Reply-To: References: <168DEFFB0E406B59.30759@groups.io> From: "Ethin Probst" Date: Fri, 2 Jul 2021 13:22:54 -0500 Message-ID: Subject: Re: [edk2-devel] EFI_AUDIO_OUTPUT_PROTOCOL: assistance with VirtIO initialization To: devel@edk2.groups.io, mcb30@ipxe.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Update: I just realized I'd made a typo -- the unknown request is actually a get_min request. On 7/2/21, Ethin Probst wrote: > Thank you for all that information, both of you. I didn't realize that > VirtIO sound would be so complicated. The specification seemed simple > enough -- but, alas, all things seem simple until you actually go and > try to implement them. > > I did manage to retrieve a packet dump, from both myself and from > somebody else that Leif contacted. The one from myself was from a USB > mixer that I have -- its how my audio headphones work, and that > generated far too many packets -- well over 5,000 at least. Utilizing > display filters wasn't much of a help either -- it doesn't seem like > my mixer makes available an audio device class descriptor anywhere, > which is odd because it should. But I also might not have been > filtering it properly. The other packet dump was sort-of helpful, but > did contain some confusing elements: > > * There were four unknown URB transfer types (0x7F) that Wireshark > claimed were "malformed". I asked around on the OSDev.org forum and I > don't think anyone recognizes that either. > * The primary init sequence was understandable, along with the get > string requests, but after that there were a bunch of URB control > transfers from device-to-host and some requests from host-to-device > containing data that I didn't understand. I wasn't sure what those > were for. They looked something like this: > > Frame 29: 36 bytes on wire (288 bits), 36 bytes captured (288 bits) on > interface wireshark_extcap1868, id 0 > Interface id: 0 (wireshark_extcap1868) > Interface name: wireshark_extcap1868 > Encapsulation type: USB packets with USBPcap header (152) > Arrival Time: Jul 1, 2021 02:21:45.291271000 CDT > [Time shift for this packet: 0.000000000 seconds] > Epoch Time: 1625124105.291271000 seconds > [Time delta from previous captured frame: 0.000008000 seconds] > [Time delta from previous displayed frame: 0.000008000 seconds] > [Time since reference or first frame: 0.035324000 seconds] > Frame Number: 29 > Frame Length: 36 bytes (288 bits) > Capture Length: 36 bytes (288 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: usb] > USB URB > [Source: host] > [Destination: 2.7.0] > USBPcap pseudoheader length: 28 > IRP ID: 0xffffa90f548b8a20 > IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) > URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b) > IRP information: 0x00, Direction: FDO -> PDO > 0000 000. =3D Reserved: 0x00 > .... ...0 =3D Direction: FDO -> PDO (0x0) > URB bus id: 2 > Device address: 7 > Endpoint: 0x80, Direction: IN > 1... .... =3D Direction: IN (1) > .... 0000 =3D Endpoint number: 0 > URB transfer type: URB_CONTROL (0x02) > Packet Data Length: 8 > [Response in: 30] > Control transfer stage: Setup (0) > [bInterfaceClass: Audio (0x01)] > Setup Data > bmRequestType: 0xa1 > 1... .... =3D Direction: Device-to-host > .01. .... =3D Type: Class (0x1) > ...0 0001 =3D Recipient: Interface (0x01) > bRequest: 130 > wValue: 0x0201 > wIndex: 1536 (0x0600) > wLength: 2 > > Frame 30: 30 bytes on wire (240 bits), 30 bytes captured (240 bits) on > interface wireshark_extcap1868, id 0 > Interface id: 0 (wireshark_extcap1868) > Interface name: wireshark_extcap1868 > Encapsulation type: USB packets with USBPcap header (152) > Arrival Time: Jul 1, 2021 02:21:45.291389000 CDT > [Time shift for this packet: 0.000000000 seconds] > Epoch Time: 1625124105.291389000 seconds > [Time delta from previous captured frame: 0.000118000 seconds] > [Time delta from previous displayed frame: 0.000118000 seconds] > [Time since reference or first frame: 0.035442000 seconds] > Frame Number: 30 > Frame Length: 30 bytes (240 bits) > Capture Length: 30 bytes (240 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: usb] > USB URB > [Source: 2.7.0] > [Destination: host] > USBPcap pseudoheader length: 28 > IRP ID: 0xffffa90f548b8a20 > IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) > URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008) > IRP information: 0x01, Direction: PDO -> FDO > 0000 000. =3D Reserved: 0x00 > .... ...1 =3D Direction: PDO -> FDO (0x1) > URB bus id: 2 > Device address: 7 > Endpoint: 0x80, Direction: IN > 1... .... =3D Direction: IN (1) > .... 0000 =3D Endpoint number: 0 > URB transfer type: URB_CONTROL (0x02) > Packet Data Length: 2 > [Request in: 29] > [Time from request: 0.000118000 seconds] > Control transfer stage: Complete (3) > [bInterfaceClass: Audio (0x01)] > CONTROL response data: 00d3 > > According to the audio 1.0 specification, this is a "get_cur" request > (appendix 9: Audio Class-Specific Request Codes). However, I wasn't > really sure what it was trying to get. The spec (SEC. B.3.3.3) > indicates that this is an input terminal descriptor. I'll continue > following this chain of requests and responses and see if I can figure > out exactly what its doing -- I need to map the request IDs onto their > actual values since Wireshark isn't doing that for me automatically. > > On 7/2/21, Michael Brown wrote: >> On 02/07/2021 10:41, Michael Brown wrote: >>> UsbIo->UsbControlTransfer(UsbIo, &Req, EfiUsbDataIn, >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 PcdGet32 (PcdUsbTransferTimeoutValue), >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 &Header, sizeof(Header), &Status); >>> >>> (Error handling etc omitted for brevity) >>> >>> That would get you the first 8 bytes of the class-specific AC interface >>> header descriptor.=C2=A0 You would then need to extract the TotalLength >>> field, allocate that length of memory, and repeat the >>> UsbControlTransfer() call to fetch the full-length descriptor into the >>> newly allocated block. >>> >>> Hope that helps, >> >> BTW, in case you aren't already aware of this: wireshark is pretty good >> at dissecting USB traffic. You can capture it by doing a "modprobe >> usbmon", after which you'll see a number of usbmonN devices show up in >> the wireshark interface list. Try them each in turn until you find >> which one corresponds to the host controller to which your device is >> attached. >> >> My normal method for developing or debugging iPXE USB drivers will >> typically involve using wireshark to capture the USB traffic that >> happens when the device is being used by a known-working driver (e.g. >> the Linux driver for that device) and comparing it to the traffic that >> happens when I'm using my own driver (via USB pass-through in a VM). >> This is often a lot faster than trying to pull together all of the >> information from the multiple USB spec documents. >> >> Good luck! >> >> Michael >> > > > -- > Signed, > Ethin D. Probst > --=20 Signed, Ethin D. Probst