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

[Hans de Goede]

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