On Thu, Nov 11, 2021 at 04:23:38PM +0100, Hans de Goede wrote: > On 11/11/21 12:18, Daniel Scally wrote: > > <snip> > > >>> One problem I'm experiencing > >>> is that the focus position I set isn't maintained; it holds for a couple > >>> of seconds and then resets to the "normal" focus...this happens when the > >>> .close() callback for the driver is called, which happens right after > >>> the control value is applied. All the other VCM drivers in the kernel > >>> power down on .close() so I did the same> > >> Right, I believe that this is fine though, we expect people to use > >> libcamera with this and once libcamera gets autofocus support, then > >> I would expect libcamera to keep the fd open the entire time while > >> streaming. > > > > > > OK - as long as that's how it works then I agree that this is fine as is > > yes. > > So I've just picked up an old project of mine, called gtk-v4l which > is a nice simply v4l2 controls applet and patches it up to also > work on v4l-subdevs: > > https://github.com/jwrdegoede/gtk-v4l/ > > So now you can run: > > sudo gtk-v4l -d /dev/v4l-subdev8 > > And it will give you a slider to control the focus; and as > a bonus it keeps the v4l-subdev open, so no more runtime-pm > issue :) > > >> What is necessary is some way for libcamera to: > >> > >> 1. See if there is a VCM which belongs to the sensor; and > >> 2. If there is a VCM figure out which v4l2-subdev it is. > >> > >> Also see this email thread, where Hans Verkuil came to the > >> conclusion that this info is currently missing from the MC > >> representation (link is to the conclusion): > >> > >> https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html > > > > > > Yeah I read through that thread too, and had a brief chat with Laurent > > about it. My plan was to add a new type of link called an "ancillary > > link" between two entities, and automatically create those in > > match_notify() based on the function field of the matching entities, and > > expose them as part of the media graph. I've started working on that but > > not progressed far enough to share anything. > > Sounds good. > > > Libcamera would need > > updating with support for that too though. > > Right I think libcamera will need updating no matter what, first we > need to comeup with a userspace API for this. > > Although I guess it would be good to also write libcamera patches > once the kernel patches are ready, but not yet merged, to make > sure the API is usable without problems by libcamera. I strongly agree with this. We're moving towards mandating a libcamera implementation to get new APIs merged in the kernel. -- Regards, Laurent Pinchart
