I've done this, it's super useful. The use case for me was that I wanted to simultaneously use two joysticks with the same game, mixing their inputs together instead of just using one or the other for each axis. The behavior only ended up being possible by writing a "joystick mux" program that would accept input from multiple joysticks, combine it, and then retransmit it as a gadget-mode device.
Side note, USB HID descriptors are a disaster and someone should do something about it. Even commercial devices by reputable manufacturers have broken descriptors. A tool with modern ergo and integration would probably get a surprising amount of traction.
This is awesome! A huge boon to digital artists those interested in HCI research. Also in rust! :)
I also noticed how problematic it is to support even major controllers like the PS4 controller under SDL. Games have to be aware of the exact model of controller that they are attached to. I was thinking you could use a RPi0 and it could "clean" all the device specific issues.
In your case, there is no reason that a FUSE like USB interposer couldn't exist purely in userland, but this is what we have.
I actually prototyped the thing in python the first time around, but performance was too poor to pass through even a single joystick, so Rust it was, lol.
As for software translation, that was out early in the design process: I needed Windows and I did not want to write a Windows device driver or fight with code signing. Nor did I want a Windows-only or Linux-only solution. So the only solution was to control the platform the software ran on (-> raspberry pi), then drop down far enough in the stack that everyone agreed on a protocol (-> USB HID). I would have been very very happy if I could have implemented this at a higher level.
Sorry, I re-read my comment and I wasn't trying to argue against you, just how messed up the OSes are and that everything is basically a stack of hacks, even the "good stuff".
I like that you prototyped it in Python first. I wonder why it didn't work? Python function call overhead?
It would be neat if there was a cross platform USB HID muxing and translation layer that used Wasm for all its logic, then the "fixups" would be portable.
I didn't do a ton of debugging before giving up and switching away from python, but I think that at least some of it was issues with the event loop and cost of serialization introducing latency.
Yeah, I think some of my irritation with the situation bled through there, lol, didn't mean to come off as aggressive. I also lament the absence of a common input standard of some sort. WASM or the like would be a neat common layer; I feel like it's a good target for embedded scripting and module systems these days.
No way to know for every game, but foot pedals for PTT is definitely a thing for controller players in competitive PVP games. They are often sold as accessibility products.
Feels like the ubiquity of these kinds of how-tos implies that the Raspberry Pi is an abundant, ready-to-hand device, which hasn't been true for a few years now. But maybe we’ll get there again soon? Seems like I’ve read people being optimistic about rpi sourcing but it also hasn’t really materialized yet.
The number of people I know who have been waiting to buy a Pi and actually get one has gone from about 1 a month to about 2 a week in the past couple months.
It's slow but steady, seeing more in stock notifications from authorized resellers on rpilocator.com, and the stock doesn't deplete for 30 minutes to an hour now, instead of like 5-10 minutes earlier this year.
Would be good if more people called this out. I said something regarding how memory inefficient software is these days and how that makes pi clones difficult to use as a sandbox and someone helpfully responded back about how I should be using some model of RPi for that.
First, I already have devices. Second, people are still waiting in like to get Pi’s and based on the last interview I saw the Raspberry people think the system is working. They don’t want to raise their prices.
I am fairly sure if you have more money to offer your suppliers that scarce components are easier to get ahold of. They could keep their margins the same and raise their rates and generate a lot more revenue.
"Call it out"? For what? Do you think the Raspberry folks are just choosing to not make enough? I'm pretty sure they don't like the current situation as much as you don't.
They've chosen to prioritize selling to businesses ordering hundreds of Pis for field-deployed devices, over individual hobbyists ordering single-digit quantities for tinkering and hacking (https://www.youtube.com/watch?v=-_aL9V0JsQQ).
They’ve chosen not to raise prices in a parts shortage and are calling it a virtue. Meanwhile the common advice is to buy them off of eBay at elevated prices. Essentially scalping.
You can pay suppliers preferential prices for preferential treatment. That has been Apple’s MO for a decade and a half.
Raise your prices until demand just starts to taper. Use the money to butter up suppliers (place bigger orders, pay cash on delivery, in advance, whatever). Get it done, stop patting yourself on the back for five years running for not being able to keep up with demand.
Given the continued prevalence of this kind of comment, I think people have missed the recent updates regarding supply chain slowly normalizing until the end of the year (you can now buy Zeros in packs of 10 at some UK a and EU retailers, at non-scalping prices).
Worse, I suspect this will become an urban legend of sorts even when there are no more shortages.
OKAY. This is a step closer to my dream idea which I feel like should be possible but haven't figured out, and am curious if anyone has done anything like this:
I want to be able to wirelessly change the music on the "USB drive" in my car; i.e. the "drive" is actually an always-on computer, e.g. a Pi.
Change the music from the computer at home and be on my way?
Yup, you can use the usb-gadget mass-storage framework to "plug in" a "block device" which is backed by a file on the computer. You can then "unplug" the device from the usb, and loop-mount it locally to manipulate its contents.
Nota bene, do not mount it two places at the same time!
Something I’d still like to add is a USB OTG emulation of iOS/Android/iPod/etc, so that the currently playing track shows on the dash, steering wheel controls can be used, etc, but my last experimentation a couple years ago didn’t go anywhere. (All the open source stuff for emulating CarPlay and Android Auto seem to be for the other direction: the dash, not the device.)
If you have a spare Android phone with enough storage, and can configure it to mount as a USB mass storage device, maybe you can install an FTP server/Syncthing client/etc. on it, use that to manage the music remotely, and plug it in to your car so that it can see the library.
I've worked on DriveDroid. There were indeed people who have done this.
Best example of such a use-case was someone who wanted to make an old printing press fetch files its files from the internet. The press only had an interface for floppy disks. He replaced the floppy disk controller with a floppy emulator that exposed an USB port. Connected a phone with DriveDroid. Synced usb image files from the internet to be exposed over usb mass storage. The image files were fat images that hold the printing job files. They were generated by the server automatically. It worked pretty well from what I heard.
For many phones it is possible to change the exposed protocol from mtp to mass storage. Mass storage does need an image file with fat filesystem to work on most devices. It nowadays is not possible to expose the phones internal storage.
I don't have much idea about these things but is it possible to make a pi act as a usb drive? Then you can plug-in a wifi-enabled pi in the usb slot of your car which can store your music files and grant you tons of control.
I use this for my Teslas Dashcam (it was built for it), but it also has a feature to rsync music files from a network share every time it connects to the network and expose it as files on a USB drive to the host. Sounds like it would cover what you want, and it supports RPI Zero Ws natively.
You could get a Toshiba FlashAir sd card, which can be read/write to from wifi. Plug that into a USB sd card adapter & away you go. Discontinued but there are some available about.
This isn't so much to build on your idea directly, but maybe some additional fodder will help further inspire ideas and yet more food for thought (for myself as well, and better yet, anyone else)..
I recently realized I can use a $15 USB capture card with an HDMI input on the other end to snag the video feed of a Pi or anything else that can output HDMI. As I use Linux, you can tap into the /dev/video<number> device as if it was a camera, using VLC/OBS. (There's also a paid app on Play store that allows me to also do this on my phone as the display side, using OTG. Would love to be able to use my tablet running a de-Googled LineageOS as well, but that'd entail figuring out how to crack/patch out Google's license checking library, and I haven't found any FOSS alternatives, ugh.)
From there, making the (my) dream happen would be if there was some convenient way to use the same device that's tapping into the video out as the keyboard/mouse input, much in the modal way of VMWare/VirtualBox, where it overtakes your input, and using the hotkeys to release when you want to switch back to your tasks on the host.
In particular, I have a Flipper Zero that doesn't get real use beyond novelty functions and have been wondering if that (or something like a ESP32/ESP8266 computer) could help facilitate that. My skillset is nowhere near that close to the metal.
At least, re: your post I'm piggybacking, and coming from knowing the capabilities of the Flipper Zero, I wonder if RubberDucky/BadUSB payloads could bring you any closer to meeting the spirit of your goal. Or, some sort of rsync like mechanism baked into the Pi when it (automatically) connects to a detected, saved network. Or, a RubberDucky/BadUSB payload on-demand to fire off an rsync.
Not all ESP32s support USB OTG and I don’t have the correct one here atm to test with. Not sure how much more work would be needed to serve files from sd card.
You could then use a web server on the esp32 to transfer your files
Perhaps a USB Armory (thumb drive computer) configured to expose a mass storage device with your music. Then push new music files to it over Bluetooth from your phone.
This works on the Raspberry Pi Zero, and the Raspberry Pi 4. I'm not sure about the Zero 2, but I know the other models lack hardware support for the feature.
You can buy a cool little PCB that attaches to the Zero and gives it a male USB-A port, turning it into a chunky flash drive or whatever. (They're sometimes referred to as a "BadUSB".)
It works on any Pi which has only 1 USB port - except for the power port. So on the various "Model A's" and on the zeros. The reason is, the Pi's SOC actually is natively capable of USB Gadget mode, but only offers 1 USB port, and on the various B models they interpose a hub to offer more ports - but gadget mode stops working due to the hub being in between.
The Pi 4 is an exception - its USB-C power port works in gadget mode too, unlike its normal USB-A ports, which do not, like all other Pis, because of said hub.
The beagleboard SBC was amazing for how setup it was. I think the stock image had serial. It also presented a network adapter & host a small network. If you connected, it would advertise a webserver, which was a web IDE for programming the device. Incredible out of box experience.
As you seem to know well this thing, I'll ask you: they write type "ssh pi@raspberrypi.local" and voilà !", but I know that just enabling an IP stack over a USB link is not enough per se* normally, the device has to have a network configuration (IP address, netmask, gateway) which usually means DHCP. Moreover, how does the ssh client computer know that "raspberrypi.local" is this device?
Yes, you have to have either some kind of network configuration, and enable the network interface that appears after you pluging in the USB device. It's no different from using USB-ethernet adapters.
The easiest is probably to rely on link local addresses and mDNS if all you need is local access from the computer you connected the device to. On a systemd based Linux distros, mDNS is enabled by default in systemd-resolved daemon. On my distro, there's no default configuration for usb network adapters, so I have to do that part by myself. Other systems may work differently and auto-enable USB interfaces and at least setup link local addresses on them. The device implementig the gadget has to do the same.
Going to toot my own horn a little bit here. I used this capability on this work project: https://github.com/nhsx/il-magic-scanner (long story short: use a pi camera to OCR ID info off a phone screen, then pretend to be a keyboard and "type" it into an attached computer). There's a spun-off standalone daemon at https://github.com/nhsx/il-keebd which handles the "pretend to be a keyboard" bit. It listens on a local socket for text, converts it to scancodes, and squirts them up to the usb host.
The keymap isn't complete by any means, but it's got enough there to be interesting.
One cool and lesser-known fact is that you can enable adb on Raspberry Pi with adbd.
It’s a fairly seamless way to get console/push/pull over USB. Only downside is that it requires the adb tool on the host as well, vs gadget serial/ssh.
I'm currently trying to do this on my little stack of Pi Zero and Zero 2 boards. I remember at some point this worked great, and then I couldn't get it to work again. So far I'm not having any success. The Pi doesn't show up as a USB device using lsusb on the host. Working my way through a stack of micro-usb cables. Maybe they all are charge only. Anyone have recent success with 64-bit Raspberry Pi OS and Ubuntu on the host end?
One of the unfortunate things about the Raspberry Pi Zero is that the second micro usb is power only. For this type of configuration I encourage all to check out the Allwinner ARM-based SoCs and boards built from friendlyelec. With the NanoPi Neo I was able to enable USB ethernet gadget mode on its micro-usb and then have it host and power another device on its USB-A (for me a mobile phone). In my use case the laptop powered both the NanoPi and charging the mobile device all from USB power while also acting a an ethernet packet router from the mobile device back to the laptop all over USB on its own subnet.
I ran out of ports on the usb charger I was using to run my little cluster so I have a couple of the lower power devices daisy chained off of the higher power ones.
It does mean that some devices will power off unexpectedly when others restart but unexpected restarts are something you have to plan for anyway.
Yeah, anything based on H3/H5 SoCs will work fine for this use case due to the SoCs having 4 separate USB host controllers, one of them muxed with OTG controller. That's a lot of I/O flexibility.
You should be able to do this with a pi 4, since the usb-c power port is also the gadget port. The usb 3.0 ones off the pcie bus on the pi should be completely independent from that and still work (not sure about the 2.0 ports or anything).
Yep, and if that does work for you, then you might be able to get closer to the form factor you want using a CM4. That said you'd have to learn how to design your own board for it and potentially handle the pcie lane. But that would be a much smaller starting footprint with it at least.
FWIW - I was able to do this using a pocketbeagle. We even did this for a small run product where Octavo SIP exposed USB Serial and Ethernet via gadget, and then was a host on the USB1 side.
Did this with a uugear mega4 ppps usb switch between two pi zero ws. One can be permanently on, drawing just 0.6watt. It can turn on the second pi zero and connect to it.
Unfortunately there seems to be a bug on Ubuntu 22.04 for Arm that, when you configure the Pi for gadget mode and log in via VNC, X locks after a few minutes. Didn’t do this on 20.04.
Side note, USB HID descriptors are a disaster and someone should do something about it. Even commercial devices by reputable manufacturers have broken descriptors. A tool with modern ergo and integration would probably get a surprising amount of traction.
https://github.com/saulrh/composite-joystick