Linux Media Controller development
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Dan Scally <djrscally@gmail.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hans Verkuil <hverkuil@xs4all.nl>, Kate Hsuan <hpa@redhat.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	libcamera-devel@lists.libcamera.org
Subject: Re: Userspace API for controlling the focus of the Surface Go [2] main/back-camera
Date: Mon, 25 Oct 2021 13:30:09 +0300	[thread overview]
Message-ID: <YXaHMd3czQy0NKJn@pendragon.ideasonboard.com> (raw)
In-Reply-To: <c7c94544-8af4-ad29-04ef-6131774e68b8@redhat.com>

Hi Hans,

On Mon, Oct 25, 2021 at 12:06:30PM +0200, Hans de Goede wrote:
> Hi All,
> 
> With my (and Dan's) kernel patch-series to enable the back camera on
> the Surface Go shaping up (and hopefully going upstream soon),
> the next step is to enable control of the focus lens for the back
> camera.
> 
> The focus is controlled through a separate i2c-client which is
> described by a 2nd I2cSerialBusV2 resource entry in the ACPI
> device for the ov8865 sensor. By default the kernel only instantiates
> an i2c-client for the first I2cSerialBusV2 resource entry for an
> ACPI device, getting an i2c-client for the 2nd one is easy and
> out of scope for this discussion.
> 
> The question which I have is, assuming we have the 2nd i2c-client
> instantiated and we have a i2c-driver binding to it, how do we
> represent the focus control to userspace.
> 
> I see 2 possible directions we can go here:
> 
> 1. Somehow inject an extra v4l2ctrl for this into the v4l2ctrl
> list of the sensor. AFAIK we don't have infra for this atm, but
> we could add some generic mechanism to do this to the v4l2-ctrls
> core. IMHO from a userspace pov this is the cleanest, but at the
> cost of some extra work / possible ugliness on the kernel side.
> 
> 2. Register a separate v4l2_subdev for the focus-ctrl and in
> some way provide information to userspace to which sensor this
> belongs.

The second approach is what V4L2 does already. We have a set of drivers
for VCMs already (search for V4L2_CID_FOCUS_ABSOLUTE in
drivers/media/i2c/).

> I believe that both are valid approaches. So before diving into
> this I wonder what others are thinking about this.
> 
> Specific questions:
> 
> 1. Hans Verkuil, what do you think about adding
> support for another driver to inject ctrls into the ctrl
> list of another v4l2(sub)dev ? Maybe something like this
> already exists ? If not do you think this is feasible
> and desirable to add ?
> 
> 2. If we go with a separate v4l2_subdev, how do we communicate
> to which sensor the focus-control belongs to userspace ?

The information was initially envisioned to be conveyed to userspace
through the media controller API, using the entity group ID to group the
camera sensor, lens controller and flash controller, but the
media_entity_desc.group_id field is now obsolete. No other mechanism
exist to replace that as far as I know, so we'll have to create
something. There have been some talks about using a special kind of link
to expose the relationship between the camera sensor and other
components.

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2021-10-25 10:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 10:06 Userspace API for controlling the focus of the Surface Go [2] main/back-camera Hans de Goede
2021-10-25 10:25 ` Hans Verkuil
2021-10-25 10:53   ` Laurent Pinchart
2021-10-25 10:30 ` Laurent Pinchart [this message]
2021-10-25 10:47   ` Hans Verkuil
2021-10-25 10:55     ` Laurent Pinchart
2021-10-25 11:18       ` Hans Verkuil
2021-10-25 11:03     ` [libcamera-devel] " Dave Stevenson
2021-10-25 11:10       ` Hans Verkuil
2021-10-25 11:17         ` Dave Stevenson
2021-10-25 11:26           ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXaHMd3czQy0NKJn@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=djrscally@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=hpa@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=libcamera-devel@lists.libcamera.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox