Something similar that I want us USB Force Feedback wheel (and joystick) support for the RP2040. I looked pretty deeply in to this and I was unable to find any libraries which do the necessary USB magic for the chip to build devices which show up on a computer as force feedback. There’s some code for the Atmega32u4 to do it and in general there is documentation around the web for how this stuff works, but actually digging in to USB spec stuff is not really my thing.
There is an open source gamepad library for the RP2040 but they said on GitHub issues and discord that they have no plan to pursue force feedback support.
But I designed a really nice brushless motor controller for the RP2040 and I’d love to make a force feedback wheel with it! I already have a motorized wheel I built to test this and I even made it work with motorized return to center as a regular USB joystick device, I just don’t know the magic incantations to make it in to a force feedback device.
If you have enough USB experience you might be able to do it by (a) adding the necessary configuration reports to expose HID force feedback and (b) implementing the matching endpoint. But it's quite fiddly and benefits from having a device you can copy.
The open source gamepad firmware you mention is GP2040-CE. I can guarantee you users will be happy if force feedback gets merged in. Stuff moves fast; by now, opinions on this might have changed. I'd encourage interested parties to join the Discord and discuss it.
I would love it if you could help! I wonder if it would be sufficient to work on it via github issues. Here is the issue I posted, which could be re-opened. I can also post on discord for you if that is helpful. Maybe you could post your interest in that issue and then I can link to it in discord and ask them to discuss it with you on the issues page?
Definitely possible, but it would ruin an otherwise nice development environment. For personal use that would be fine, but I tend to try to design things as nice complete open source projects people could use and enjoy using. Plugging in to one USB port to program the RP2040 and then another to test the force feedback control is not ideal for development.
It would work though, and I do want a wheel even for myself (the surplus motor I got for it is a beast). Might be my best bet.
Imagine something like this but having two USB inputs, one for the keyboard and one for your phone. Then your phone could inject passwords managed in the password manager in your phone. No need to keep them in the cloud.
Unfortunately I don't think Android supports acting like a HID device. But possibly custom firmware in the dongle could support some USB serial protocol.
That's the exact opposite model of what I built [1], because I view the phone as just as unreliable as desktop or laptop. Actually even less reliable, given my choice of workstation OS.
I went with a USB and BLE chip on the external side of my keyboard to connect to both workstation and phone to push the passwords, MFA, and encrypted text from the manager I built into the keyboard itself.
Acting like USB HID and hosting USB HID devices are two different things, GP's suggestion might be possible with Android Open Accessory(aka abusing adb in Google sanctioned way) or through a rooted phone with a custom kernel mode gadget driver.
An RP2040 device with 2 USB downstream facing port and 1 USB upstream facing port can be made, stuffed into a conspicuous Y-cable, appropriately programmed and appear as a single USB keyboard. Out of my reach but not impossible.
Just going to through out there that you don't need a custom kernel driver to do this on Android. There's a userspace gadget API; you only need a rooted phone to have the permissions to access the relevant device and config files.
ESP32-S2, ESP32-C3 and ESP32-S3 have USB-OTG to act as USB Hosts. I've seen cheap ESP32-S3 boards with two USBC connectors, one for USB-OTG and the other to connect to the PC.
edit: Actually the port to connect to the PC goes through a UART chip, so you can't emulate HID devices using that port. So it won't work.
Do you have a suggestion for a Bluetooth HID bridge? To use Bluetooth mice and keyboards with a generic dongle that presents as a usb HID to the computer, similar to how apple does peripheral support?
This seems purpose built for me. I ordered a foot pedal online with the intention of hooking OBS up to it. It seems to send a 'b' keydown event when it's pressed, with no clear way to change it. Utterly useless out of the box lol.
If you know just a little bit of electronics, for something like a pedal it might be more straight forward to take it apart, wire up the pedal switch directly to rpi pico and run something like QMK or any other usb keyboard firmware on it. That way avoiding the complexity of pedal->usb->pi pico->usb->computer. Full USB hid stack and supporting arbitrary HID device as input can be ridiculously complex.
And since you are skipping the redundant USB step, you can also use dumb non USB pedals. There are plenty of options available meant for sewing machines, midi keyboards and industrial equipment. Just need to watch out as some of them contain a potentiometer for modulating the output instead of on/off switch. That may or may not be what you want. It should still be possible to emulate regular switches with them, but it will require a bit more coding.
This is more suited for moderate complexity HID devices where direct rewiring is less practical due to amount of inputs (keyboard) or size constraints+non trivial undocumented sensors(mice, barcode scanner, other specialized input devices), or don't want to take it apart.
Too many games consider AHK to be high risk for scripting and raises your anti-cheat score. So I am wary of running AHK when playing games which have anti-cheat.
I'm thinking this remapper would get some buttons working on some old USB keyboards that have driver issues. BUT, the cost and time to make one of these remappers makes it only useful in very extreme circumstances where buying a alternate replacement device is not possible, feasible or desirable.
Looking at the store page is refreshing my memory. I ended up being unwilling to install the sketchy software. I just took it for granted it would come with a sensible default. Mouse3+, or a joypad input. Something.
This looks really awesome. It could easily replace a dozen AHK scripts on my system...
And, despite its obvious usefulness, this can also be used as base for a device to mess with coworkers. Change the firmware so that it rotates the mouse "north" by an arbitrary value between -30° and +30°, slowly changing over time. Or randomly remap keyboard keys to other neighboring keys but only once every n seconds/minutes. Just enough to evade suspicion. So many possibilities :-D
I saw this video [0] from the creator of this project the other day. Here he shows how to connect a USB joystick with a playstation access controller [1] by mapping from USB to 3.5mm analog output.
I found this because I was looking for something else for the access controller.
It's basically the other way around: I want to use the controller on a mac and need to remap it's outputs to something useful. I don't have a playstation and apparently you need one to remap the controller keys once before plugging it in to a PC, otherwise only 3 out of 8 buttons will send something that is recognized as USB HID
You could totally use HID Remapper to do what you want.
The PlayStation Access Controller has profiles that can be configured from a PS5 as you say, but regardless of the current profile or mapping, it always sends the raw button/joystick states in the report. They're not properly exposed in the report descriptor, but they're there. You would have to use what HID Remapper calls "custom usages" to get to this raw data. I can assist you with that if you're interested. Though it might be easier to find someone with a PS5 for the one time setup.
Sadly, the firmware for the CYW43439 is a binary blob provided in the form of C header files[1] -- even though it's free for commercial use[2] as long as it's used with a RP2040 like in the Pico W.
I always wonder with these things if game anti-cheat software will flag you based on the hardware identifiers not matching known manufacturers of peripherals.
Multiple OS installs / multiple boxes on the same keyboard.
Then it's "do it 4 times in software for free" and the software is not the same and this solution suddenly becomes attractive.
You could solve it by getting a keyboard that supports macros on the keyboard hardware maybe. Or keep your existing keyboard you know and love and insert this little solution.
I use a keyboard with qmk which is quite similar to this, before that I used a bunch of autohotkey scripts. To me qmk is a better solution since it works on any computer and any programs (autohotkey struggles with some applications that I belive use lower level input handling, I cannot speak for Karabiner since I don't use it), without needing to install anything. To me is a big plus
I think the processing power necessary to do this at modern resolutions (1080p60/4k/etc.) is way out of any rpi's league. Usually this is done on an FPGA which is exactly what makes it so expensive.
"PiKVM receives the entire signal, but then the encoding is the bottleneck. For 1080p, this is no more than 30 fps. V4 throws out every second frame of 60 hz/fps, and 30 fps is encoded. V3 and DIY can't process 60 hz and is only able to capture 50 hz, and in the same way they take every second frame, all you get out is 25 fps. The reason why V3 and DIY does not encode 30 out of 50 is that the picture will be jerky, but smooth at 25."
The main website claims 1080p60 support, which is true on the input side, but that's not what you get on the output... a bit of false advertising IMO.
I read that too, and wonder about the usefulnes of this feature.
If your mouse has a sample rate of, say, 100Hz, what benefit does it bring to increase that to 1000Hz? You would still get 10 samples with the same data, then the next 10, and so on...
But then the mouse "natively supports" 1000 Hz? OP said it helps with devices that don't "natively support it". The GitHub page calls it "polling rate overclocking" (whatever that means), which doesn't sound like it would "unlock" anything (or "ask nicely" as you put it) in the mouse but rather just increase the sampling frequency?
For reference, most mice sensors have sampling frequency in excess of 5000fps on the low end, but the data is consolidated and reported at a 125hz usb polling rate.
Something similar that I want us USB Force Feedback wheel (and joystick) support for the RP2040. I looked pretty deeply in to this and I was unable to find any libraries which do the necessary USB magic for the chip to build devices which show up on a computer as force feedback. There’s some code for the Atmega32u4 to do it and in general there is documentation around the web for how this stuff works, but actually digging in to USB spec stuff is not really my thing.
There is an open source gamepad library for the RP2040 but they said on GitHub issues and discord that they have no plan to pursue force feedback support.
But I designed a really nice brushless motor controller for the RP2040 and I’d love to make a force feedback wheel with it! I already have a motorized wheel I built to test this and I even made it work with motorized return to center as a regular USB joystick device, I just don’t know the magic incantations to make it in to a force feedback device.
Some discussion of how to do this in a PIC context: https://forum.microchip.com/s/topic/a5C3l000000M4PDEA0/t2469...
If you have enough USB experience you might be able to do it by (a) adding the necessary configuration reports to expose HID force feedback and (b) implementing the matching endpoint. But it's quite fiddly and benefits from having a device you can copy.
The open source gamepad firmware you mention is GP2040-CE. I can guarantee you users will be happy if force feedback gets merged in. Stuff moves fast; by now, opinions on this might have changed. I'd encourage interested parties to join the Discord and discuss it.
Well they even closed the github issue after some discussion, determining it was "not on our roadmap any time soon", but maybe I could ask again. https://github.com/OpenStickCommunity/GP2040-CE/issues/515
I would love to help add force feedback support, but I cannot use Discord.
I would love it if you could help! I wonder if it would be sufficient to work on it via github issues. Here is the issue I posted, which could be re-opened. I can also post on discord for you if that is helpful. Maybe you could post your interest in that issue and then I can link to it in discord and ask them to discuss it with you on the issues page?
https://github.com/OpenStickCommunity/GP2040-CE/issues/515
ah sorry, I don't use github either https://sfconservancy.org/GiveUpGitHub/
That’s fair. Hard to balance participating in open source community with standing up for our rights.
sacrifices must be made sometimes.
Use the atmega32u4 and it's force feedback implementation to handle the USB communication? Communicating with it over I2C or similar?
Definitely possible, but it would ruin an otherwise nice development environment. For personal use that would be fine, but I tend to try to design things as nice complete open source projects people could use and enjoy using. Plugging in to one USB port to program the RP2040 and then another to test the force feedback control is not ideal for development.
It would work though, and I do want a wheel even for myself (the surplus motor I got for it is a beast). Might be my best bet.
Imagine something like this but having two USB inputs, one for the keyboard and one for your phone. Then your phone could inject passwords managed in the password manager in your phone. No need to keep them in the cloud.
Unfortunately I don't think Android supports acting like a HID device. But possibly custom firmware in the dongle could support some USB serial protocol.
That's the exact opposite model of what I built [1], because I view the phone as just as unreliable as desktop or laptop. Actually even less reliable, given my choice of workstation OS.
I went with a USB and BLE chip on the external side of my keyboard to connect to both workstation and phone to push the passwords, MFA, and encrypted text from the manager I built into the keyboard itself.
1: https://www.anomie.tech/products/anigma/ce/
I don't keep passwords in the cloud because I'm afraid they'll be stolen from my computer, I keep them there for backup.
And you use the passwords from the cloud to test your ability to restore from backup? ;).
No no, I have them memorized.
Even the OTPs? :).
I mean the reason I use BitWarden instead of KeePassX isn't because I'm worried someone will steal the KeePassX database file, but that I'll lose it.
Anrdoid and iOS don't support USB HID natively. The iPod does with Rockbox, but I'm probably the only person still carrying one around.
The best solution I've found for pocket-sized USB HID is an EspUSB Tiny:
https://github.com/cnlohr/espusb
It's an ESP8285 acting as a USB keyboard, with the keystrokes coming over WiFi from a nearby phone.
Acting like USB HID and hosting USB HID devices are two different things, GP's suggestion might be possible with Android Open Accessory(aka abusing adb in Google sanctioned way) or through a rooted phone with a custom kernel mode gadget driver.
An RP2040 device with 2 USB downstream facing port and 1 USB upstream facing port can be made, stuffed into a conspicuous Y-cable, appropriately programmed and appear as a single USB keyboard. Out of my reach but not impossible.
Just going to through out there that you don't need a custom kernel driver to do this on Android. There's a userspace gadget API; you only need a rooted phone to have the permissions to access the relevant device and config files.
http://www.linux-usb.org/gadget/usb.c
ESP32-S2, ESP32-C3 and ESP32-S3 have USB-OTG to act as USB Hosts. I've seen cheap ESP32-S3 boards with two USBC connectors, one for USB-OTG and the other to connect to the PC.
edit: Actually the port to connect to the PC goes through a UART chip, so you can't emulate HID devices using that port. So it won't work.
Do you have a suggestion for a Bluetooth HID bridge? To use Bluetooth mice and keyboards with a generic dongle that presents as a usb HID to the computer, similar to how apple does peripheral support?
Are you looking for a product, or one to build yourself?
If you want a product, why not just get a USB-Bluetooth adaptor? It would support HID as well as A2DP (music) and other Bluetooth protocols.
If you want to build something, I'd recommend getting a board with an ESP32.
The ESP32 comes with plenty of example code in their esp-idf SDK. You'd be needing:
esp-idf/examples/peripherals/usb/device/tusb_hid
esp-idf/examples/bluetooth/esp_hid_host
A rooted android can.
https://github.com/tejado/android-usb-gadget
You can set up a network connection over USB (intended for tethered operation).
Or just use kdeconnect.
..Or iOS, Windows.. or Mac..
This seems purpose built for me. I ordered a foot pedal online with the intention of hooking OBS up to it. It seems to send a 'b' keydown event when it's pressed, with no clear way to change it. Utterly useless out of the box lol.
If you know just a little bit of electronics, for something like a pedal it might be more straight forward to take it apart, wire up the pedal switch directly to rpi pico and run something like QMK or any other usb keyboard firmware on it. That way avoiding the complexity of pedal->usb->pi pico->usb->computer. Full USB hid stack and supporting arbitrary HID device as input can be ridiculously complex.
And since you are skipping the redundant USB step, you can also use dumb non USB pedals. There are plenty of options available meant for sewing machines, midi keyboards and industrial equipment. Just need to watch out as some of them contain a potentiometer for modulating the output instead of on/off switch. That may or may not be what you want. It should still be possible to emulate regular switches with them, but it will require a bit more coding.
This is more suited for moderate complexity HID devices where direct rewiring is less practical due to amount of inputs (keyboard) or size constraints+non trivial undocumented sensors(mice, barcode scanner, other specialized input devices), or don't want to take it apart.
I will assume it's the same foot pedal that I have, in that case the software is at https://pcsensor.cn/software-details?_l=en
You could probably use autohotkey to detect when that device sends a "b" and intercept it.
Too many games consider AHK to be high risk for scripting and raises your anti-cheat score. So I am wary of running AHK when playing games which have anti-cheat.
Then rip out the insides and replace them with a microcontroller.
Completely agree.
What on Earth? :(
Was it a lot cheaper than the Elgato one?
https://www.amazon.com/Elgato-Stream-Deck-Pedal-footswitches...
I'm thinking this remapper would get some buttons working on some old USB keyboards that have driver issues. BUT, the cost and time to make one of these remappers makes it only useful in very extreme circumstances where buying a alternate replacement device is not possible, feasible or desirable.
Much cheaper. https://www.amazon.com/dp/B08MC456TC
Looking at the store page is refreshing my memory. I ended up being unwilling to install the sketchy software. I just took it for granted it would come with a sensible default. Mouse3+, or a joypad input. Something.
That's a lot cheaper! :)
This looks really awesome. It could easily replace a dozen AHK scripts on my system...
And, despite its obvious usefulness, this can also be used as base for a device to mess with coworkers. Change the firmware so that it rotates the mouse "north" by an arbitrary value between -30° and +30°, slowly changing over time. Or randomly remap keyboard keys to other neighboring keys but only once every n seconds/minutes. Just enough to evade suspicion. So many possibilities :-D
I saw this video [0] from the creator of this project the other day. Here he shows how to connect a USB joystick with a playstation access controller [1] by mapping from USB to 3.5mm analog output.
I found this because I was looking for something else for the access controller. It's basically the other way around: I want to use the controller on a mac and need to remap it's outputs to something useful. I don't have a playstation and apparently you need one to remap the controller keys once before plugging it in to a PC, otherwise only 3 out of 8 buttons will send something that is recognized as USB HID
[0] https://www.youtube.com/watch?v=MtXdPWN6NBw [1] https://www.playstation.com/en-us/accessories/access-control...
You could totally use HID Remapper to do what you want.
The PlayStation Access Controller has profiles that can be configured from a PS5 as you say, but regardless of the current profile or mapping, it always sends the raw button/joystick states in the report. They're not properly exposed in the report descriptor, but they're there. You would have to use what HID Remapper calls "custom usages" to get to this raw data. I can assist you with that if you're interested. Though it might be easier to find someone with a PS5 for the one time setup.
> It works completely in hardware
No, it works completely in software, it's just on a different CPU. Still neat though!
It turns out the RP2040 is turning out to be a really nice microprocessor.
The only thing missing is Wifi really.
The Pico W connects the RP2040 to a CYW43439 over PIO. Works pretty well.
It does!
Sadly, the firmware for the CYW43439 is a binary blob provided in the form of C header files[1] -- even though it's free for commercial use[2] as long as it's used with a RP2040 like in the Pico W.
[1] https://github.com/georgerobotics/cyw43-driver/tree/main/fir...
[2] https://github.com/georgerobotics/cyw43-driver/blob/main/LIC...
> Sadly, the firmware for the CYW43439 is a binary blob provided in the form of C header files
This is Hacker News - let's start reverse-engineering it. :-)
Its BLE needs more work - note that project uses the nrf52840. Its pretty feature complete
I always wonder with these things if game anti-cheat software will flag you based on the hardware identifiers not matching known manufacturers of peripherals.
There are so many manufacturers of USB peripherals in the world that trying to allowlist "known" manufacturers would be futile.
Trivial to spoof if one were so inclined.
I've been planning on turning an old ambidextrous Logitech Marble Mouse into a cheap CAD spacemouse and this might be just what I need.
I don't see the point except for rare fixed applications without admin OS access. Do it in software for free. Karabiner Elements etc.
Multiple OS installs / multiple boxes on the same keyboard.
Then it's "do it 4 times in software for free" and the software is not the same and this solution suddenly becomes attractive.
You could solve it by getting a keyboard that supports macros on the keyboard hardware maybe. Or keep your existing keyboard you know and love and insert this little solution.
I use a keyboard with qmk which is quite similar to this, before that I used a bunch of autohotkey scripts. To me qmk is a better solution since it works on any computer and any programs (autohotkey struggles with some applications that I belive use lower level input handling, I cannot speak for Karabiner since I don't use it), without needing to install anything. To me is a big plus
I recently thought about using a cheap USB HDMI capture card (7 bucks) and a RP2040(7 bucks) to build a PiKVM like device.
Connecting the 2040 via serial emulating USB keyboard and mouse would make it possible to use older rasperry pi 3 devices for pikvm.
This project seems to prove that this is possible...
I think the processing power necessary to do this at modern resolutions (1080p60/4k/etc.) is way out of any rpi's league. Usually this is done on an FPGA which is exactly what makes it so expensive.
Mmh thanks for you response. PiKVM[1] is a ready to use product an it works on >= RPI4... So if this was correct, how would you explain?
1: https://pikvm.org/
"works" is subjective: https://docs.pikvm.org/faq/#common-questions
> I am expecting to see 60fps and I am not, why?
"PiKVM receives the entire signal, but then the encoding is the bottleneck. For 1080p, this is no more than 30 fps. V4 throws out every second frame of 60 hz/fps, and 30 fps is encoded. V3 and DIY can't process 60 hz and is only able to capture 50 hz, and in the same way they take every second frame, all you get out is 25 fps. The reason why V3 and DIY does not encode 30 out of 50 is that the picture will be jerky, but smooth at 25."
The main website claims 1080p60 support, which is true on the input side, but that's not what you get on the output... a bit of false advertising IMO.
I use an Apple keyboard on my work PC, but would rather use Command-C and Command-V instead of Ctrl-C and Ctrl-V.
This remapper should be able to remap the Command/Windows key to Ctrl.
For that case I use the Powertoys Keyboard Manager. Powertoys is a windows must install, in my opinion. Surprised it's still not installed by default. https://learn.microsoft.com/en-us/windows/powertoys/
Also useful if you want a 1000Hz mouse who doesn't natively support it.
I read that too, and wonder about the usefulnes of this feature.
If your mouse has a sample rate of, say, 100Hz, what benefit does it bring to increase that to 1000Hz? You would still get 10 samples with the same data, then the next 10, and so on...
Or am I missing something here?
It just doesn't work the way you describe.
Many mice are capable of higher reporting rates than their defaults, they just need to be asked nicely.
But then the mouse "natively supports" 1000 Hz? OP said it helps with devices that don't "natively support it". The GitHub page calls it "polling rate overclocking" (whatever that means), which doesn't sound like it would "unlock" anything (or "ask nicely" as you put it) in the mouse but rather just increase the sampling frequency?
For reference, most mice sensors have sampling frequency in excess of 5000fps on the low end, but the data is consolidated and reported at a 125hz usb polling rate.