E.g. https://github.com/torvalds/linux/blob/master/Documentation/usb/gadget-testing.rst or configfs--usb-gadget-xxx files in https://github.com/torvalds/linux/tree/master/Documentation/ABI/testing
That file is a gadget coding hint, I do not think anyone cares much about that file and nobody bothered to update it (apart of a few formatting changes https://github.com/torvalds/linux/commits/master/Documentation/driver-api/usb/gadget.rst ). New composite functions are created with code/inspiration from the existing ones.
I'm playing a bit with gadget mode on a Pine Quartz64 A board (link: https://www.pine64.org/quartz64a/)
This uses the dwc3 usb controller (instead of dwc2 on the pi4). I'm running Manjaro with kernel 6.2.5.
First it was a bit of a pain to get the gadget to work at all. I needed to modify the device tree, specifically these two commands:
IIUC this should enable th gadget on two separate usb ports, but only one of them works. I have tried countless other combinations like setting only one of them to "device", setting one or both to "peripheral" (what's the difference?) or "otg", but nothing else works.
Right now it works, but with a bunch of problems.
It only works at 16 bits. Trying 32 bits (S32_LE) gives stuttering garbage. I haven't tried 24 bits but I'm not really optimistic about that.
I can only get it to work on Windows. A linux box finds it but playback fails. A mac doesn't find it at all.
Another problem is that I'm missing the capture pitch adjust:
So I kindof have it working a little bit, but it's not good enough to use for anything. Anyone have any ideas for things to try?
This uses the dwc3 usb controller (instead of dwc2 on the pi4). I'm running Manjaro with kernel 6.2.5.
First it was a bit of a pain to get the gadget to work at all. I needed to modify the device tree, specifically these two commands:
where /boot/dtbs/rockchip/rk3566-quartz64-a-otg.dtb is a copy of the standard /boot/dtbs/rockchip/rk3566-quartz64-a.dtb
IIUC this should enable th gadget on two separate usb ports, but only one of them works. I have tried countless other combinations like setting only one of them to "device", setting one or both to "peripheral" (what's the difference?) or "otg", but nothing else works.
Right now it works, but with a bunch of problems.
It only works at 16 bits. Trying 32 bits (S32_LE) gives stuttering garbage. I haven't tried 24 bits but I'm not really optimistic about that.
I can only get it to work on Windows. A linux box finds it but playback fails. A mac doesn't find it at all.
Another problem is that I'm missing the capture pitch adjust:
Where is my "Capture Pitch 1000000"?
So I kindof have it working a little bit, but it's not good enough to use for anything. Anyone have any ideas for things to try?
Update on that, it seems I was somehow using the uac1 gadget, not uac2.
New try via configfs, using this script (adapted from here: https://forums.raspberrypi.com/viewtopic.php?t=333504):
This works much better. 16&32 bit both work, and the capture pitch is back. Works on windows and linux, only the mac doesn't like it.
New try via configfs, using this script (adapted from here: https://forums.raspberrypi.com/viewtopic.php?t=333504):
This works much better. 16&32 bit both work, and the capture pitch is back. Works on windows and linux, only the mac doesn't like it.
The gaudio module is basically a hard-coded composite configuration, which picks the audio function based on kernel configs
https://github.com/torvalds/linux/b...5/drivers/usb/gadget/legacy/audio.c#L268-L277 . The module offers only some of the composite config options via its module params. The gaudio module is deprecated (configfs is the preferred way) and kernel admins do not welcome new features to that module (typically adding new parameters).
Most likely your kernel config has the option CONFIG_GADGET_UAC1 enabled. Typically distributions include the kernel configs in /boot/config-CURRENT_KERNEL_VERSION, that's often handy to check.
This writeup seems very instructive https://www.collabora.com/news-and-...-and-how-to-integrate-it-with-systemd-part-1/ Basically udev detects a new UDC device (the OTG port switched from host to device) and triggers some activation which builds the configfs chain. Upon the UDC device removal (the OTG port switched from device to host) udev triggers some deactivation command.
I probably did something wrong before, there is no need to touch usb@fd000000. This is enough:
This quartz board is somehow configured so that it can't auto-switch between host and device (read something about some pin that should have been connected for that to work). Selecting "otg" makes the port device only.
Now let's see if I can get this to start on boot..
And the mode should be "otg" and nothing else, "device" is not a valid option and makes it revert to the default which happens to be "otg".
This quartz board is somehow configured so that it can't auto-switch between host and device (read something about some pin that should have been connected for that to work). Selecting "otg" makes the port device only.
Now let's see if I can get this to start on boot..
All set up! I'm listening to spotify on windows -> usb to quartz64 (with camilladsp capturing from the gadget) ->usb to Motu M4. It has been nice and stable for an hour or so.
The gadget configfs is set up by a systemd service at boot. Camilladsp also runs as a systemd service that is started by a udev rule when the dac connects.
The gadget configfs is set up by a systemd service at boot. Camilladsp also runs as a systemd service that is started by a udev rule when the dac connects.
My setup doesn't have it, but it could be done.
You can use the Pavel's gadget controller to handle the changes. I think there is some post about that somewhere but I don't remember where.
https://github.com/pavhofman/gaudio_ctl
And collabora.com says ...
So declaring ...
echo 0x0104 > idProduct # Multifunction Composite Gadget
... as advocated in the raspberry forum and applyed by Henrik then would make the host providing the cdc_ether driver. But we have an audio gadget here. Is this really the perfect match ??? I think there might be another, specific idProduct code for an audio gadget? Or not?
IMO the product ID in this case does not mark any driver, if the device complies with standard USB functions and does not require a custom driver (which could be tied to the specific PID).
Yes, it's true Linux Foundation has put a few PIDs into the USB database https://the-sz.com/products/usbid/index.php?v=0x1D6B but IMO these are not critical. Linux Foundation has no custom drivers for windows, OSX etc.
Yes, it's true Linux Foundation has put a few PIDs into the USB database https://the-sz.com/products/usbid/index.php?v=0x1D6B but IMO these are not critical. Linux Foundation has no custom drivers for windows, OSX etc.
Thank you for the link and your comments. So, peeping into your link
0x0104 stands for a Multifunction Composite Gadget (which might include ethernet as well as audio)
and instead
0x0101 would stand for the specific Audio Gadget
Well then, let's go along with the RaspiPibians and with Henrik for ID 0x0104 which seems perfect for our maybe multifunctional audio needs.
0x0104 stands for a Multifunction Composite Gadget (which might include ethernet as well as audio)
and instead
0x0101 would stand for the specific Audio Gadget
Well then, let's go along with the RaspiPibians and with Henrik for ID 0x0104 which seems perfect for our maybe multifunctional audio needs.
I already made a small attempt to add a network interface. I used a windows host, and could make it recognize the audio gadget or the network adapter, not both at the same time.
After giving up I found this: https://github.com/RoganDawes/P4wnP1/blob/master/boot/init_usb.sh
Looks promising and worth another try.
After giving up I found this: https://github.com/RoganDawes/P4wnP1/blob/master/boot/init_usb.sh
Looks promising and worth another try.
IMO the PID really does not matter, if the USB descriptor contains valid standard USB functions for which built-in drivers of the OS exist.
IIUC the issue is with windows which caches the combination VID+PID+firmware_version (bcdDevice) for a particular USB driver. If the functionality changes, some of it needs to be changed to restart driver installation.
See the notes in https://github.com/RoganDawes/P4wnP1/search?q=pid https://github.com/RoganDawes/P4wnP...c07caab8b7/payloads/stickykey/trigger.txt#L30