HID VS Smoothieware

I don't think the built-in keyboard library identifies itself as "boot capable" in the HID descriptor, which is necessary for simpler keyboard devices. Try using NicoHood's HID library with the "BootKeyboard" object.

Looks great! How did you handle the programming? Did you follow a guide, or did you implement the Arduino HID Project library?

Skip the esp then and pick up any dev board supported by the HID project.

You can make it act like a HID - which is what I assume many people have done - with custom drivers like this one. https://github.com/NicoHood/HID

You can use Arduino HID Project which allows to reprogram atmega16u2 which performs USB communications on Uno. Then you can upload HID sketch on 16u2 and "normal" code on atmega328 which would do everything and send desired wheel state via serial. On 16u2 side you will parse that serial command from 328 and translate it into HID message

I'm trying to grab the "microphone muted" LED status from the HID library, but it seems like the library only supports a select few statuses out of the box: https://github.com/NicoHood/HID/issues/151

https://github.com/NicoHood/HID for a real UNO

Nano (atmega328) doesnt have native USB support (just a USB to UART converter). UNO also doesnt have native USB support, but has a atmega16U2 on board. You can flash this chip and build a USB HID bridge -> https://github.com/NicoHood/HID/

Try using NicoHood's HID project and the system key page: https://github.com/NicoHood/HID/blob/master/examples/System/System.ino

I originally wrote Teacup because I was horrified at numerous aspects of the state of other 3d printer firmware codebases available, but after a few years I became far more interested in Smoothie and officially relinquished leadership of Teacup to Traumflug who'd been doing far more work on it than me at the time

Also, Windows' USB stack is a complete dumpster fire - in Linux your thing just needs to say "hi I've got camera interfaces" in the device descriptor and you're mostly good to go, but Windows needs actual driver development, or at least a magic text file to tell it to use its preinstalled drivers.

Fwiw I wrote the runtime descriptor construction code for smoothie which is how I know it's possible - and yet even after a decade, I don't see any other firmware libraries with similar descriptor construction mechanisms which is sad.

Smoothie has a dynamic device descriptor, and adding an extra serial port via config setting is a fairly reliable way to bluescreen windows.

There's a few forum threads around (eg this one regarding the Teensy arduino core), but I haven't seen any firmware stacks with the dynamic USB descriptor initialization and endpoint allocation you'd need for runtime custom USB function sets other than the one I wrote for Smoothie a decade ago.

PS: USB in a nutshell is a great read if you're planning to work with USB firmware stacks - was super helpful when I was massaging Smoothie's USB stack

Bizarrely however, you need a magic text file to convince windows to actually use it with a particular device - despite the fact that USB was specifically designed for this to be entirely unnecessary as devices must describe themselves to the host on connect and there are many standardized interface patterns.

I've been thinking of creating a 3D printer to print buildings or maybe a CNC machine for milling lumber out of these trees. I've got an upper-end Smoothieboard so I could do that.

I've been fairly happy with Smoothieware http://smoothieware.org