[libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))

[Laurent Pinchart]

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