A broader variety of controllers would indeed be helpful. When you have
the stuff integrated the way you think it's right, just tell me and I'll
test if it still works on our testbed.
It's not as if the protocol actually _needs_ an interrupt endpoint,
though the MSFT spec says it does. It's actually simpler for the host
to poll for completion on the control endpoint; none of the requests
should take very long to finish anyway. An RNDIS host might not even
notice those "toggle broken" issues.
You probably underestimate the mental sensibility of Windows machines.
We have seen cases where the Windows host just floods you with
interrupts when it is not happy with things like these...
Did you have any evidence that the MSFT host was actually using that
interrupt endpoint? Like CATC snooping showing it never tried to
collect responses until the interrupt packet arrived?
We have seen the packets with the protocol analyzer. I think we agree
that using an interrupt endpoint just to announce that the gadget has a
message for the host available, but that's how M$ designed it...
Also, which versions of MS-Windows did you test against? Some of the
MSFT docs suggest version-specific protocol quirks.
Win 98, XP, 2000. Auerswald currently tests all available other
variants, and the tests they invented are _really_ crazy ;)