A key bit of information that might clear up some confusion - USB gadgets are the main peripheral-side USB interface in the Linux kernel.
When you plug an embedded Linux device like a phone into something, it could use USB gadgets to expose internal storage as a mass storage device, create a tty and expose that as a USB ACM/CDC device, etc- and using the gadget mechanism, allocate USB endpoints to each of these functions, and enable or disable them at runtime.
So, this project seems to be allowing a Linux device to emulate arbitrary peripherals to an external USB host.
But you certainly could know more than me about it! Why do you think it's exclusively for acting as a USB gadget connected to the Linux kernel it's running on?
It looks like I'm only partially right: dummy_hcd is just for the local kernel, but raw gadget is just yet another interface to the UDC, so like usb functionfs just without sanity checks.
This is really fantastic. I am currently building my own keyboard with my own controller and it will be much easier for me to first implement mock controller in userspace before I try to get it right on external device. Especially because I will want to put some complicated functionality in it like steno.
I don't think you need that for this. The keyboard firmware likely consists of three big chunks, the USB code, the matrix scan, and the processing of the matrix scan data into keystrokes. The USB stack is likely a peripheral on your microcontroller, which they have in theory already tested. The matrix scan will need to be tested on real hardware. The processing code should be abstracted enough from USB and matrix scanning that you can just compile it for your host machine and write tests the usual way (given matrix state x then y, output state should be foo).
For final integration tests, you can use an additional microcontroller to be the key matrix. Instead of wiring up keyswitches, wire the microcontroller to the matrix pins, and have it accept commands over the serial port to set the matrix to a certain state. This way, you can do a full end-to-end test on your real hardware.
The only place USB gadget emulation might be helpful is in writing the code that switches the keyboard from compatibility mode (6KRO) to the NKRO mode. It's been done a million times, though, so there is plenty of library code to just copy.
First, this is going to be my first USB device. Second, I plan to put some more complex functionality. I intend it to be my last keyboard so I want to be able to map every key however I want (the whole point of having my own controller). I also want it to have built-in steno which is much more than just matrix scanning.
While I could achieve all of that with OS driver and plover the sad reality is that I am unable to install my own software on my corporate PC and I would like to have consistent environment at my home and office.
All I'm saying is that the interesting part of the code will run just fine on your host machine, so you don't need any complicated tricks to develop and test it. Obviously in production it will run on the microcontroller, so you get the functionality you desire without OS drivers.
Do keep in mind that /usr/share/dict/words is about 10x larger than the flash on microcontrollers. This is why most people do the steno conversion in software, not on the keyboard itself.
If you're not designing your own microcontroller, you might want to check out the Proton-C. It has 248kB of usable flash memory, which could be enough to store a stenography-optimized word list in addition to the firmware. It was made to be flashed with the qmk keyboard firmware, but I don't think there's any requirement that you have to use qmk.
I used an STM32F103 for my last keyboard, and you can buy four for the price of a Proton C. I am still not sure why they chose the F3 series for the Proton C, as it doesn't seem to be a chip that's commonly used in the maker community. I am somewhat surprised they didn't bite the bullet and just port QMK to the nRF52 (since everyone wants bluetooth out of the box), actually.
The F103 is also interesting in that it is well-supported by Rust and Tinygo, if C isn't your thing. I picked it because QMK supports it (and works great), but I'm actually planning to write the firmware in Go and ditch all the things that bug me about QMK. However the USB stack is not there and I dread writing it. I might pull a QMK and just have ChibiOS run my Go code ;)
The F3 series includes support for "analog peripherals," so maybe they decided on that line so they could support the speaker? If that's correct, then that's a pretty niche feature for them to focus on. There are forks of qmk and the pro-micro that support the nRF52, but as far as I can tell nothing has been merged into the main qmk yet.
I was actually planning to run it on F103 as I already have couple of them laying around. And I also wanted to try it in Rust mostly to get some experience with it.
I was initially thinking about something that is already bluetooth enabled like ESP32 or CC2640R2 (I have development boards for both of these) but the design suddenly gets exponentially more complex if you want to get it right. Also, neither has a package that I can easily solder. I know it is just aesthetics, but I really like a clean board.
So the idea is to have a kind of blank slate, 40 to 60% ortholinear keyboard, that I will be able to experiment with.
The base layout will be a small grid that will fit traditional (ie. dvorak;) layout but that I will also be able to change to my liking. I plan to be able to experiment with 3d printed keys to support traditional steno or maybe some other chorded method. I don't have much experience with steno so I want to keep my options open.
Configuration and dictionaries will be provided on an SD card.
The keyboard will be reversible (ie. the enclosure such that it will be possible to rotate entire mounting plate with the switches and PCB) to provide negative slope.
And yes, it will be RGB because even if the keys are not marked it is still nice to be able to see individual keys in the dark for more complicated Emacs bindings...
If I were trying to do the project you are talking about, I would experiment with coming up with a way for a Raspberry Pi running Plover to act as a usb gadget to connect to your work PC. I'd think it'd also be quite simple to get Plover to output words over serial to an atmega32u4 that can act as a HID keyboard.
So you have keyboard -> RPi with Plover -> Atmega32u4 -> Work PC.
Then you don't have to come up with the chording/dictionary support yourself.
In fact I've had a very similar project on the backburner myself. I'm planning to eventually end up with an nrf52840 combined with a RPi Zero W, so the entire device can act as a bluetooth keyboard with chording support for any PC or phone that can use a bluetooth keyboard.
RPi Zero would be possible to put inside the keyboard (aside from its physical footprint) although it will limit where I can connect the keyboard (due to power drain). But then I will also have to forget about bluetooth and making it battery powered later because 200mA is I think the lowest I could get with this design with bluetooth enabled.
Bit of clarification is apparently needed. The loopback USB emulation is already in mainline via CONFIG_USB_DUMMY_HCD
What this new module provides is new userspace API to the gadget subsystem, making the dummy hcd much more practical especially for testing USB driver code
Neat. Can you clarify what "emulate" means? Would this let me implement a USB gadget on a Linux board with a device-side USB port, without writing a kernel module?
When you plug an embedded Linux device like a phone into something, it could use USB gadgets to expose internal storage as a mass storage device, create a tty and expose that as a USB ACM/CDC device, etc- and using the gadget mechanism, allocate USB endpoints to each of these functions, and enable or disable them at runtime.
So, this project seems to be allowing a Linux device to emulate arbitrary peripherals to an external USB host.
Prior work in this area: see Facedancer. Neat.