RFC: API change: Make CameraManager provide a list of CameraDescription objects

[Hans de Goede]

Hi,

On 9/1/24 2:34 AM, Laurent Pinchart wrote:
> On Tue, Aug 27, 2024 at 06:55:00PM +0200, Hans de Goede wrote:
>> On 8/27/24 6:02 PM, David Plowman wrote:
>>> On Tue, 27 Aug 2024 at 16:25, Hans de Goede wrote:

<snip>

>> Milan is trying to add a generic libcamera configuration file concept,
>> the latest version of Milan's patches are here:
>>
>> https://lists.libcamera.org/pipermail/libcamera-devel/2024-June/042916.html
>>
>> Note this patch set could really use some help wrt someone reviewing it.
> 
> See above for the mea culpa. I'll try harder.

<somewhat offtopic>

Actually my "could really use some help wrt someone reviewing" remark was
not targeted at you (Laurent). I was trying to stimulate others to do
more reviewing. Having you do all the reviews does not scale.

Actually this is also something where I want to do better myself. E.g.
I should be able to review Milan's software ISP cleanup series. But atm
my priorities are at closing bugs in pipewire video/libcamera support
before these ship to end users in Fedora 41. Once that is done I'll
hopefully have some bandwidth to help out with reviews.

</somewhat offtopic>

<snip>

>>>>>> - This keeps kernel resources associated to the fds tied-up all the time
> 
> That isn't necessarily a downside. Allocating all resources ahead of
> time helps making sure we won't fail allocating them later. That's
> important in safety-critical systems for instance. This being said,
> those application can simply acquire/get/create the camera at
> initialization time.

Right, in some cases this pre-allocating / acquiring resources may be
desired, but not always. The new API will allow for both scenarios.

>>>>>> - In some cases (e.g. uvcvideo, atomisp, VCM subdevs) this will keep
>>>>>>   the device associated with the /dev node powered up all the time leading
>>>>>>   to a significant increased battery drain
> 
> For atomisp, should this be fixed on the kernel side ?

Yes and I have a TODO list item for this and I have even written somewhat
of a plan how to tackle this. But this is somewhat involved which means
this basically is another case of me needing to find the bandwidth to
handle this for anything to happen here.

> For VCMs, we need
> to revisit power management on the kernel side, it has been implemented
> without a design :-S

Ack. I have been thinking about this and I think that VCM v4l2-subdev-s
should start implementing v4l2_subdev_video_ops.s_stream and then
do a pm_runtime_get_sync() on s_stream(1) and pm_runtime_put() on
s_stream(0).

I think the s_stream() calls on the VCM can be added to the existing 
call_s_stream() wrapper similar to how this already controls
the privacy-led if one is present.

I plan to prototype this s_stream() approach on some atomisp devices
and post a RFC patch-set to the linux-media list.

<snip>

Regards,

Hans