Ports number mismatch - between /dev/videoN and argus_camera utility

Something strange - I attach 5 cameras to ports 1, 5, 6, 10 and 11

All cameras are recognized as video devices.
All cameras can stream video using argus_camera application.

The problem is that the camera numbers are not the same when using v4l2-ctl (for streaming or settings) and for viewing video with argus_camera

/dev/ name | actual port on D3-like board | argus_camera number
----------------- | ------------------------------------- | ------------------------------
video0 | 1 | 0
video1 | 5 | 3
video2 | 6 | 4
video3 | 10 | 1
video4 | 11 | 2

It seems that the argus_camera utility “sees” the ports in “alpha-numeric” order - 1, 10, 11, 5, 6
When using port 2 instead of port 1 - the argus_camera order is 10, 11, 2, 5, 6

Any idea how to resolve this issue? The problem arises when I want to set a parameter using v4l2-ctl on the same camera that I also want to stream frames from.


hello mechi.fendel,

may I know what’s the actual use-case.

the video device sysnode, i.e. /dev/videoN is not match to the sensor-id directly.
instead, it’s looking device tree property for position, the Module Properties within the tegra-camera-platform{}.

We have a proprietary board with 16 camera connections based on the D3 NVIDIA® JETSON AGX XAVIER FPD-LINK™ III INTERFACE CARD

Every 4 cameras share a DES ub960
Each camera on each port has its own SER ub953

Before streaming video using :

gst-launch-1.0 nvarguscamerasrc sensor-id=${ID} ! fpsdisplaysink text-overlay=false video-sink=fakesink -v

I need to use

v4l2-ctl -d {video-dev-node} -c

to set some of the controls.

Since the argus_camera gives numbers according to alpha-numeric order, and /dev/video devices are numbered according to actual numerical order of ports, I have to keep a “translation table” a not so pretty workaround.

I was wondering if there’s another solution.
I’ve already written the dtsi files according to what’s suggested in :


Capture using nvarguscamerasrc with V4L2 Controls using an Unstable Camera System

Nothing they suggested seems to work.
Any idea?