USB implies one end will be a host, the other will be a device. The host is in control. The JTK1 micro-USB connector is type “On The Go” (OTG), so either a micro-A or a micro-B connector will fit…if it is a micro-A connector, then the connector will behave as a host and you can plug in normal stuff, e.g., keyboard or mouse. If the connector is used with micro-B, then then the Jetson becomes a device (no specific device is programmed, so unless you set it up, device mode is inert with the exception of recovery mode…recovery mode is a custom device in device mode). It sounds like you want the Jetson to be a device.
When the host queries the device (when Windows asks the Jetson what it is via the micro-B connector), the device can respond with some pre-existing device templates. In order to keep every device in the world from needing its own specialized driver, a generic USB interface was created for known common devices. One class is human input device, or HID. If you have a keyboard, mouse, or game controller, and if it implements a standardized interface for this, then the host does not need to search for a brand-specific driver. Similar examples would include a video device following USB Video Class template, or a hard drive following the Bulk Storage class template. Because your device will not follow a common template for a known class, it is custom. See:
When a device plugs in to a host, the host sees this event and enumerates…which means it asks the device what it is. Your device will respond with a custom device ID, and not with a standardized type. An event of plugging in of this device ID will generate a message within the host’s kernel to announce the device, and a driver which knows this device (which you will write) will claim ownership.
On the device side you will need to detect a type-B connector (OTG can use type-A or type-B). When seeing a type-B connector (when Jetson gets a type-B insert event), any query by the host will need a Jetson reply with standard USB information. Part of that information will be this custom ID. Everything that follows will be your code as a Linux kernel driver taking ownership upon type-B insert event, and your code within the Windows kernel driver taking ownership upon enumeration of that ID insert event…USB just becomes a pipe, everything else is built by you.
You will need to implement your drivers to work in some particular transfer mode, presumably one of isochronous, bulk transfer, or interrupt mode. I’m guessing you would be interested in interrupt mode.
The gadget interface is an aid to rapid prototyping of the pre-existing device classes. If you are building your own brand of some generic device, this would apply to you:
Since your device is custom, this will not apply; however, the information is still correct, except your template won’t be one of those known classes. You’ll basically be writing for a gadget, and then you’ll also need to create the gadget code itself since your device is custom. Since you are interested in interrupts, the closest device type to start with is the HID class for keyboards.