Hi Daniel, On 11/23/21 13:10, Daniel Scally wrote: > Hi Hans > > On 11/11/2021 15:23, Hans de Goede wrote: >> Hi, >> >> 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 :) > > > This is just neat regardless of the problem we were having; thanks! > >>>> 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. > > > Realised I'd not updated you on this for a while - I've got the new > style of links created by the kernel when the fwnode match is made, and > those are visible in userspace, I'm just working on hacking libcamera to > accomodate them too. cpp is new to me though so it might take me a while That is good to hear. You mau have noticed I've been a bit quiet too. I've been busy with other drivers/platform/x86 stuff, but I hope to wrap that up soon and post a v6 of the INT3472 / surface go back camera series, including VCM support. Regards, Hans
