Re: [PATCH] media: uvcvideo: query pan/tilt position from the device on every read

Hi Ricardo,

On Fri, 31 Jul 2026 19:14:51 +0200, Ricardo Ribalda <[email protected]> wrote:
> How accurate does the mapping frame/position need to be?
>
> You do not know how big the camera pipeline is. Maybe you are
> processing frame NOW-4 when you read position NOW

Not accurate at all, and I should have been clearer earlier: I picked
"the former" for the continuous part of your question, not for the
frame-tagging example. Nothing in my use case correlates a position
with a particular frame. The position is an input to a control loop
("where am I, so I can ask for ten degrees left of here") and a number
on a UI, and the gimbal's own time constants are hundreds of
milliseconds per move, so a few frames of pipeline skew is far below
anything that matters.

If someone did want frame-accurate pose, I agree a G_CTRL read would be
the wrong instrument entirely -- that is a per-frame metadata problem,
and this patch would not be the right vehicle for it.

> unrelated note: if you need to set the two axis at the set time, you
> can use  V4L.VIDIOC_S_EXT_CTRLS
> [...]
> In fact you could use that today to avoid part of the kernel issue.
> Always send pan and tilt when you are tracking the movement.

Thanks -- and you are right that this sidesteps the merge problem
completely, which I had not appreciated. Both mappings land in
UVC_CTRL_DATA_CURRENT before the single commit, so whatever
__uvc_ctrl_load_cur() put there is fully overwritten and it no longer
matters which source the RMW pulled from. I will switch my userspace to
always send both axes. It does not touch the read side, but it makes
the write side a non-issue for me in the meantime.

> If AUTO_UPDATE is present you would get fresh data when you poll the
> control.

One clarification for the record, since it bears on what you are asking
HansV to weigh: that holds via the interrupt rather than via the poll.
uvc_ctrl_status_event() clears ctrl->loaded, so a poll after a
notification does re-read the device -- but polls between notifications
still return the cache, because __uvc_ctrl_load_cur() returns early on
ctrl->loaded and nothing else clears it outside a commit. So on a
compliant autoupdate device the update rate is the device's signalling
rate, and for pan/tilt 4.2.2.1.15 only promises that signal at the end
of the movement. Good enough for "it stopped, here is where"; not for
sampling a trajectory. I mention it only so the comparison is accurate,
not to relitigate -- your framing of the two problems matches how I see
them.

> You definitely have to ping the vendor to make sure they fix their
> firmware.

Agreed, and I will. I am not counting on a timeline.

> Let's wait a bit for Laurent or HansG (or even Hans Verkuil) to
> comment.

Sounds good -- no rush at all from my side, and I am happy to respin
against whatever shape you all land on. Enjoy the time off.

Best regards,
Michael Jordan