USB HID device supported ?


We plan to use tegra tx2 with configfs usb HID device (simulation of touch screen).
Is it supported with tegra ? i.e. can its device peripheral controller can be used to simulate HID device ?

Thank you,

Jetsons are just Ubuntu with extra drivers for accelerated hardware access. HID is standard among all Linux installs. On the other hand, many touch screens have their own driver and are not necessarily HID class even if they are HID in purpose. I have not set up a touch screen though, so I cannot tell you what is available for use with a touch screen.

Under “lsusb” you can see devices listed with an ID. You can limit the specific lsusb query to that ID via the “-d” option. For example I have a cheap mouse on a TX2 showing as:

Bus 001 Device 003: ID <b>093a:2510</b> Pixart Imaging, Inc. Optical Mouse

I can then see a verbose listing via:

sudo lsusb -d 093a:2510 -vvv

If I grep for “Class” I see driver information:

sudo lsusb -d 093a:2510 -vvv | egrep Class
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass

The bInterfaceClass implies the generic HID drivers work for this. The subclass implies the BIOS will try to use this mouse if working from a PC (Jetsons don’t have a BIOS). Anything showing as “Vendor Specific Class” is something requiring its own driver and would not truly be HID until the custom driver is running. If you have a USB touchscreen, then you can use this to tell what it is.

On the other hand, if a non-hot-plug system is used (such as GPIO or serial ports), then you are guaranteed you need to set this up manually and will need to have knowledge of how this specific touch screen is set up.


Thank you very much for the information.

I think the answer you gave is more related to usb devices connected to usb host (tegra).
But I am actually asking if tegra can be used as a device, so when it is connected to other cpu (running windows for example), the other PC will see tegra as a usb device.
I haven’t yet checked the source but I see there is CONFIG_USB_TEGRA in kernel ? If so, it might add support in kernel for usb device controller.
I also wander if “lsusb” shows one of the device as “usb device controller” ? If so, it means that there is a support in HW inside tegra for usb device controller.
Do you see it listed on jetson tx2 (I don’t have yet a HW to check myself).

Thank you,

A port in “host” mode is what your average connector is. Physically it is a “type A” connector for up through USB2. USB3 is also what you might consider a one-way pairing of a host to a device, but the type-C connector is a bit smarter. In the case of a type-A the other end must be type-B.

Type-B is for device. A keyboard or mouse is a HID device. There must always be a host-to-device connection. Neither host-to-host nor device-to-device is allowed.

The port you are interested in is the micro-USB port if you are using the dev carrier. There are also micro-A and micro-B connectors, but in this case the port is micro-OTG (On the Go). This is not a magic connector which gets around the type-A or type-B pairing requirements, but it does have the ability of either a type-A or type-B plugging in…then there is an ID detect pin so the operating system knows which type to treat this connector as. This is why the micro-OTG can become a device.

Turning this port into a device is done in Linux via the “gadget” framework. Provided the cable connecting is a type-B (and the supplied micro-USB cable is type-B since in recovery mode the Jetson is a device and not a host). The trick there is that you must create the code as to how the device behaves. Simply plugging in the right cable won’t make the port become anything in particular. It just happens that people have become accustomed to certain devices having particular behaviors (e.g., a cell phone becoming mass storage), but that is because someone wrote the code to make that particular device behave as such.

FYI, USB devices have various modes. Some devices used for real time streaming use “isochronous” mode. This mode is not supported by the particular port. All other modes are supported in device mode (including interrupt mode which HID would use). So you are in luck if you are willing to complete the customization steps needed to use gadget framework. See:

This may or may not apply, depending on whether you are using a recently flashed system or not, but I’m adding this for completeness:


Thank you very much for the information.
It seems that the link is more relevant with android, but we use the default filesystem (ubuntu).

Thank you,

The USB standards are the same across Linux and Android, and within the kernel Android is also Linux. So far as gadget framework goes, this works on Jetsons via Ubuntu. I have not tried to use gadget on Android, but the kernel information would be the same as in Ubuntu.

The real issue is usually that people need to know how to create an HID device or camera or bulk storage device or some other device to bind to the gadget framework (software which behaves as if it is hardware linked into USB where the user doesn’t know it isn’t real hardware). All device mode setups on every device made is essentially a customization of that device and involved someone working with kernel code (either directly or by using someone else’s customization examples). Gadget itself just tells you how to use existing kernel bindings without writing it all from scratch, but you do still have to write code.