I hope this message finds you well. I am writing to report a peculiar issue I have encountered with the camera sensor driver on the AGX ORIN 32G platform running Jetpack 5.1.2.
Description of the issue:
After booting up, when I load the camera sensor driver and use the v4l2 interface to capture video streams, everything works as expected. However, the problem arises when I subsequently use the argus_camera utility for display. Upon returning to use v4l2, the operation becomes blocked, and upon termination with ctrl+c, a substantial number of error messages flood the dmesg logs. I have attached screenshots of the relevant error messages and the sequence of operations for your reference.
I kindly request your assistance in investigating the possible causes of this issue and any potential solutions.
Thank you very much for your attention and support.
I am aware that I cannot use v4l2 and argus simultaneously for camera access. As mentioned earlier, my scenario involves opening the camera using argus, closing it, and then attempting to capture images using v4l2. It is during this latter stage that the operation becomes blocked. If there’s any part of my description that needs clarification, please feel free to point it out.
Due to certain circumstances, using argus is not always the optimal choice for us. We tend to switch to the v4l2 method to obtain raw images. However, it seems there are issues now. If I remember correctly, I tried the same operation on Jetpack 5.1.1, and it seemed to work fine there. However, that was on Orin NX, so I am not sure if it’s directly related to the software.
it looks like you’re trying to access to the camera node via v4l2 while argus_camera application is shutting down.
could you please give it a try by adding 5-sec delay before v4l2 start access to video stream.
BTW,
the purpose for running v4l2 pipeline only for Raw images captures?
if yes, how about execute with nvargus_nvraw utility for verification?
Thank you for your suggestion. Despite not being visible from my terminal, I assure you that I have introduced a delay of at least a few minutes between closing Argus and attempting to stream with the v4l2 interface. Surprisingly, in subsequent tests, v4l2 still fails to resume capturing frames. This is quite perplexing, as it appears that Argus is somehow still occupying the camera and preventing further usage.
BTW,
The primary reason for using the v4l2 pipeline exclusively is for capturing raw images. Regarding your suggestion to use the nvargus_nvraw utility for verification, I will certainly give it a try and provide feedback.
Hi, Nvidia
Using nvargus_nvraw is a feasible solution, but in our evaluation, the robustness and stability of the argus program appear to be inferior to v4l2. If possible, we still prefer to use v4l2 for capturing raw images. Do you have any other suggestions?
FYI, I’m testing with Jetpack-5.1.3/r35.5.0, we cannot reproduce this issue locally.
for example, it works normally by opening the camera using argus , closing it, and then attempting to capture images using v4l2 .
Hi, Jerry
I’m glad to hear that it works well on Jetpack 5.1.3, but unfortunately, our current version is 5.1.2. Additionally, due to the use of our custom-made carrier board, upgrading the system version is not straightforward for us.
It involves a wide range of changes and could potentially introduce more issues. If possible, please make sure to validate it on Jetpack 5.1.2 as well!
FYI,
we’ve tested and confirmed we cannot reproduce issue on JP-5.1.2 (r35.4.1) as well.
it might be your camera driver bug, had you review the sensor termination status?
Hi, Jerry
A perplexing situation has arisen where you’re unable to reproduce my issue. As depicted in the images I shared at the beginning of the problem, there are no issues with repeatedly capturing images using v4l2 when Argus is not in use. I believe if there were any abnormal states in the driver’s termination, I wouldn’t be able to flexibly use v4l2 before employing Argus.
Certainly, I appreciate the testing you’ve conducted on Jetpack 5.1.2; this result is crucial for us. Moving forward, we’ll focus on thoroughly examining any issues with our driver program. If you have any valuable suggestions, please do share them with me.
If the inspection yields unsatisfactory results, we might consider resorting to the nvraw method. However, it’s not the most optimal solution for us.
