No video node is created when a USB camera was connected to the TX2.

Hello,everyone.Recently I’m using GStreamer pipelines for H265 encoding,and I use the Basler USB cameras for capturing pictures.Some plugins of GStreamer pipelines such as v4l2src need to find ‘dev/video’.However,when I connect a Basler camera to TX2,there is no new video node created under the dev folder.I tried to ask the Basler Customer service for help and they say the Basler USB camera doesn’t obey to UVC protocol and obey to USB protocol,so you’ll not find a video node under the dev folder.

So if there is some way to solve this problem so that it appear to video node under dev folder?

If Basler is saying the camera uses a non-standard custom driver then there will be no “/dev” file until the driver is loaded.

USB is just a data pipe with the ability to query what the device is. A large number of cameras use a “standard” USB video class driver, which means they conform to a generic interface and do not need a custom driver…they still need a driver, but the generic driver is always present. Custom drivers will need to be installed as an extra step.

The files in “/dev” are not real files…these are a reflection of what a device driver produces. No driver, no file. In the case of the “/dev/video#” files this is a convention for USB Video Class (UVC) devices and a custom driver would use a different name (UVC is a separate driver from the USB data pipe, but it won’t work with a non-UVC camera)…so even if you have the driver it would be expected the name would not be that of a normal USB camera (the “/dev/video#” naming would change for anything not UVC).

Does Basler provide a special driver (or better yet the source code) for 64-bit arm64/aarch64/ARMv8-a?

I sent a e-mail to Basler for this question right now. Did you mean even if I installed the driver,there is probably no ‘dev/video#’ created and it is created in another form?If so,in gstreamer pipelines,can I use the name xxx the way same as the name ‘dev/video#’ so that it also can recognise it?In other word,even if the node is not the form of ‘dev/video#’,as long as I can find it,I can use it for gstreamer pipelines?

Correct. If the driver does not adhere to the interface which the UVC drivers (which come with USB, but are not exactly USB drivers), then some other naming convention would be used. Whether or not you can use it just depends on the driver.

There is a constant reminder in any literature you read about code development on any UNIX style system (anything following the POSIX standards…UNIX is just a trade name) that “everything is a file”. This includes hardware devices accessed through files. Base access, if supported, can be performed on all of the drivers via open/close and read/write operations common to an ordinary file.

Some drivers have customization because they need more than basic file operations. Any calls to a driver which do not adhere to the standard file operations instead use an “ioctl” (I/O control) interface…a variable argument list of custom functions (not unlike the C variants of the printf function which handles any number of arguments via a variable argument list). The ioctl is called against the file descriptor just like ordinary file operations, but failure to support this in the driver will result in an error. There are cases, such as the video devices of the UVC drivers, where a large number of video device manufacturers have chosen to give the same ioctl and basic file operations as the method of operating their device. If the two devices use a driver which implements the ioctl and basic file operations in the same way, then the programs which use the one driver can use the other driver (and hardware behind the driver) interchangeably. Perhaps some program made some requirement for a certain name convention in what device special file naming convention is allowed, but in reality compatibility depends on the ioctl interface and file interface and is not dependent upon a device special file (pseudo) name.

It also would not be uncommon for a device to work with a given class while also extending that class. As a contrived example, suppose your camera is UVC. Now assume the camera has a built in light to use for flash, and that light can operate at either thermal or visible light range. That extra control needed would require extra ioctl driver additions, but the rest of the camera could operate just like any other UVC camera. Any generic driver would be able to load and use the basic camera, but you would need special software to operate the light. Special software for that camera would have no way to do anything new to any other standard UVC device, but would probably be able to run basic camera operation for some other manufacturer’s UVC camera.

When a USB device is plugged in the device is queried and the nature of the device is broadcast to drivers so that qualified drivers can see if they want to take ownership. In the case of the verbose USB plug in details (“sudo lsusb -vvv” shows this…which can be limited to a single device via the ID using the “-d whatever:whatever” ID) picking a driver to load depends on what the device advertises during its capability query. The device could respond with more than one capability, e.g., a custom lighting control plus a standard camera. The standard camera most of the end user software expects to see is a UVC device because it is a published standard which an enormous number of devices follow. With no such declaration from the camera that it is UVC the camera must fall back to a custom driver and no “standard” driver will work (this is true even if the camera is otherwise UVC compliant because the broadcast of the device type doesn’t tell the UVC drivers that they will work).

If the end software checks that the device is UVC class, then a non-UVC camera might be rejected even if the file and ioctl interfaces match. On the other hand, a program which only checks for certain functionality via those interfaces will work regardless of whether the device is UVC or custom (the software might “probe” to see the response of the ioctl to determine support). If a manufacturer of software intends their software to only work with USB devices, then simply refusing anything not explicitly broadcast as UVC would occur. On the other hand, there are many devices which need to function under both PCI and USB, in which case the software might be more sophisticated and check the interface compatibility through some form of probing instead of something more generic.

Since your camera does not broadcast its capabilities as UVC, then no standard UVC driver can take ownership. A custom driver knowing about this device would chose to load and create the “/dev” pseudo file (the name of which is up to the driver and perhaps the udev system renaming it). If the custom driver implements the same file operations and ioctl calls on that device special file, then UVC programs could possibly work if forced to use the device special file.

Thank you so much,linuxdev.