Jetson nano 2gb not showing /dev/video

t.t (54.5 KB)
Just getting started with Jetson, but unable to get video working… I am missing /dev/video - how do I understand the reason for the problem? I have attached output from dmesg - if that is helpful…

The presence or absence of “/dev/video#” is due to whether or not the driver for a standard UVC (USB Video Class) camera has loaded, which in turn depends on the camera (A) supporting that spec, and (B), being passed through correctly by USB (USB does not implement the driver, it only passes data through…but UVC is always present since it is “standard”).

So the first step is to know if the camera is indeed UVC class and not a proprietary driver. Can you provide a URL to the camera, especially one which might mention drivers or class? We can also see what happens as you plug the device in. Monitor “dmesg --follow” while the camera is not connected. Then plug in the camera. What shows up in the “dmesg --follow” log upon plugin? Also, when plugged in, what do you see from “lsusb” and “lsusb -t”?

Hi @linuxdev! thanks for getting back to me. I didn’t give you enough details - sorry - I am using a raspberry pi camera connected to to the camera port. The camera board says “Raspberry Pi Camera Rev 1.3”.

Still important to know:

  • If you monitor “dmesg --follow”, what shows up as new log as you plug in the camera?
  • What do you see from “lsusb”?
  • What do you see from “lsusb -t”?

Thanks for your help, I have updated my camera with one that is supposed to be NVIDIA compatible:

Here is the information you requested:
lusb output:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 038f:6001
Bus 001 Device 004: ID 045e:07f8 Microsoft Corp. Wired Keyboard 600 (model 1576)
Bus 001 Device 003: ID 1a40:0801 Terminus Technology Inc.
Bus 001 Device 002: ID 03f0:1041 Hewlett-Packard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lusb -t output:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 7, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 2: Dev 7, If 1, Class=Video, Driver=uvcvideo, 480M

dmesg --follow produces this when I plug in the USB camera:

[ 1922.101517] usb 1-3.2: new high-speed USB device number 9 using tegra-xusb
[ 1922.451169] usb 1-3.2: New USB device found, idVendor=038f, idProduct=6001
[ 1922.451192] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1922.451207] usb 1-3.2: Product: USB 2.0 Camera
[ 1922.451221] usb 1-3.2: Manufacturer: lihappe8 Corp.
[ 1922.458693] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (038f:6001)
[ 1922.473953] uvcvideo 1-3.2:1.0: Entity type for entity Processing 2 was not initialized!
[ 1922.482137] uvcvideo 1-3.2:1.0: Entity type for entity Extension 6 was not initialized!
[ 1922.490546] uvcvideo 1-3.2:1.0: Entity type for entity Camera 1 was not initialized!
[ 1922.498772] input: USB 2.0 Camera as /devices/70090000.xusb/usb1/1-3/1-3.2/1-3.2:1.0/input/input9
[ 1924.993370] usb 1-3.2: usb_suspend_both: status 0

I do not find this manufacturer in the USB manufacturer ID list. Perhaps they are new and the database I’ve viewed is not yet updated. It does mean I cannot look up the specs with the ID though.

The above says this is probably a stereo camera, and is running at USB2 speeds. The root HUB is itself only capable of USB2 speeds. If the camera is actually intended for USB3 speeds, then apparently the signal was downgraded and reduced to USB2. If this is actually a USB2 device, then the stereo camera is operating as expected. If not USB2, then the camera is operating correctly, but not using its full capabilities.

The dmesg content suggests USB2 is correct and not a downgrade. Looks like this also identifies the manufacturer as “lihappe8 Corp.”. Software has determined that this is a standard interface device and does not need a custom driver (at least for the camera port…some cameras will also have control hardware which might be custom, but I see no indication of this being the case). The UVC driver is correct for the device, and USB is trying to hand off this device to the UVC driver. The UVC driver is failing to work with the device.

The reason why the UVC driver is failing to work with the camera is unknown. This does not look like a signal quality issue. Instead, this looks like a quirk in the camera. There are many USB devices with such a quirk, and there is actually a lot of kernel code in existence for adjusting to quirks, but this device is likely so new it isn’t known. One reason I say this is because I did not find the manufacturer ID in the USB database. One would need to have the camera available long enough for someone to adjust for such quirks…I just doubt this has been visible long enough for someone to fix the issue.

Still, there is some minor possibility something else in the software is an issue, but this is a tiny probability. It would be interesting to see, when you monitor “dmesg --follow” on a desktop PC, what messages occur upon plug-in of the camera. Do you have a Linux PC you can examine this with and post the results?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.