Looking at the code for setting High Dynamic Range (HDR) I see that Video4Linux is used to enable HDR at the camera level and libcamera at the SOC/RP1 level. The set_subdev_hdr_ctrl() tries to set V4L2_CID_WIDE_DYNAMIC_RANGE for the first 8 V4L sub devices. If HDR is enabled on any of the sub devices works it is assumed to be enable at the camera level if it fails on all then it is enable (if supported) at the SOC/RP1 level. This will always work when only one camera is connected but has a few holes if 2 camera are connected with different HDR hardware capabilities. The comments in set_subdev_hdr_ctrl() “it's not obvious which v4l2-subdev to use for which camera!” imply that it might be possible to match the sub device to camera. In the best of all worlds, I would match the sub device to the camera to solve the issue.
I am writing a 2 concurrent camera version of rpicam-vid so looking for advice on best way to handle this.
A)Try to match sub device to camera.
B)Only enable on either camera or pi but not both for a run.
C)Allow to be double enabled (both camera and pi).
D)Some great idea from one of you![😊]()
It is possible to match the sub device to the libcamera ID? And if so, how?
How bad would it be to over enable HDR at both the camera and board (Module3 camera on a PI5 board)?
I am writing a 2 concurrent camera version of rpicam-vid so looking for advice on best way to handle this.
A)Try to match sub device to camera.
B)Only enable on either camera or pi but not both for a run.
C)Allow to be double enabled (both camera and pi).
D)Some great idea from one of you
It is possible to match the sub device to the libcamera ID? And if so, how?
How bad would it be to over enable HDR at both the camera and board (Module3 camera on a PI5 board)?
Statistics: Posted by wkeeling — Fri Aug 09, 2024 7:54 pm