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

Michael Jordan <[email protected]>
Newsgroups org.kernel.vger.linux-media,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Hi Ricardo,

On Fri, 31 Jul 2026 19:14:51 +0200, Ricardo Ribalda <[email protected]> wrote:
> You definitely have to ping the vendor to make sure they fix their firmware.

Done -- I wrote to OBSBOT on 4 August covering the GET_INFO stub along
with two other compliance defects I found on the device (a control
default outside the control's own min/max, and PanTilt-Relative
returning a constant). No response so far. I will report back if that
changes.

One thing I should have made explicit earlier, since it bears on
whether this patch is the right general-case fix rather than a quirk
for one broken camera: correcting that firmware would not make the
position observable.

The driver clears the control cache in exactly two places --
uvc_ctrl_status_event() on a Control Change interrupt, and
uvc_ctrl_commit_entity() after a SET_CUR commit for auto-update
controls -- and __uvc_ctrl_load_cur() re-arms it after each read. So on
a fully compliant device a host-commanded move yields two samples, both
endpoints: the first G_CTRL after the commit reaches the device, but it
runs microseconds after the command, when the actuator has not yet
moved, and every later poll returns that value frozen until the
end-of-movement interrupt. Under autonomous tracking there is no commit
and no defined interrupt, so nothing invalidates the cache at all.

So the limit is the caching model rather than the device. That is the
case I would want the patch judged on, and it applies to correct
firmware too.

Worth flagging one side effect if OBSBOT does fix GET_INFO: with
AUTO_UPDATE reported, uvc_ctrl_commit_entity() would begin clearing
ctrl->loaded on this camera, so single-axis writes issued tens of
milliseconds apart would start merging against live data and cancelling
each other -- the second failure mode I measured. It would move the
device from one horn of the read-modify-write question to the other,
which is the pre-existing problem you identified and which this patch
deliberately does not touch.

No action needed from my side while we wait for Laurent, HansG or
HansV. I am still happy to respin with the autonomous-tracking case
argued in the commit message rather than in this thread, if that would
help whoever picks it up.

Best regards,
Michael Jordan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.