Ryan Summers

Worth noting is the conversation happening in https://github.com/rust-embedded/embedded-hal/issues/229, as we will likely want to follow a very similar pattern here.

I'm not sure this would belong in usb-device given that USB has no concept of an OS. There are only USB hosts and devices. A USB host may very well...

> USB enumeration process indeed looks differently depending on OS, and these differences can be used to create heuristics for OS detection. Is it possible to do this with this...

Given that there are no plans to implement this into `usb-device` currently (and I don't foresee this as feasible either), I'm going to close this issue. Thanks for bringing up...

I think the right approach here is to follow what smoltcp does. Specifically. the user is required to supply a control pipe buffer. This eliminates the need for feature flags...

I'm going to close this issue because it isn't clear to me that this is an issue with `usb-device`. If you feel otherwise, please post/update this issue :)

I couldn't resolve the merge conflicts directly here, but it looks like everything's been tested and working, so I made a PR with a minimal set of changes in https://github.com/rust-embedded-community/usb-device/pull/114...

I actually poked around at the raw gadget API recently and was trying to wire usb-device up to it to get integration testing running via CI, but I similarly hit...

I was looking into using raw-gadget as a way to emulate a USB device (running `usb-device`) to have it enumerate under linux. I had it mostly implemented, but I ran...

The idea was that the gadget would not be hardware (it would be a software module that talks through some /dev/raw-gadget file descriptor, but I wouldn't call it a virtual...