From: Michael Jordan <jordan.mymail@gmail.com>
To: Ricardo Ribalda <ribalda@chromium.org>,
Hans Verkuil <hverkuil+cisco@kernel.org>
Cc: Michael Jordan <jordan.mymail@gmail.com>,
laurent.pinchart@ideasonboard.com, hansg@kernel.org,
mchehab@kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: uvcvideo: query pan/tilt position from the device on every read
Date: Fri, 14 Aug 2026 19:33:39 -0400 [thread overview]
Message-ID: <20260814233339.973623-1-jordan.mymail@gmail.com> (raw)
In-Reply-To: <CANiDSCsS-JJrGMaoBqR-XX54dtp_uQEVVSct-BWL0gQNL4OfRQ@mail.gmail.com>
Hi Ricardo,
On Fri, 31 Jul 2026 19:14:51 +0200, Ricardo Ribalda <ribalda@chromium.org> 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
prev parent reply other threads:[~2026-08-14 23:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 21:23 [PATCH] media: uvcvideo: query pan/tilt position from the device on every read Michael Jordan
2026-07-31 8:33 ` Ricardo Ribalda
2026-07-31 15:15 ` Michael Jordan
2026-07-31 17:14 ` Ricardo Ribalda
2026-08-01 5:00 ` Michael Jordan
[not found] ` <CAMdm4Cz-oREZfk2-_eQ16umQawWF+c9vA_AV4tBuHHvsbP0vqw@mail.gmail.com>
2026-08-18 11:30 ` Ricardo Ribalda
2026-08-21 9:03 ` Michael Jordan
2026-08-27 7:30 ` Ricardo Ribalda
2026-08-14 23:33 ` Michael Jordan [this message]
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=20260814233339.973623-1-jordan.mymail@gmail.com \
--to=jordan.mymail@gmail.com \
--cc=hansg@kernel.org \
--cc=hverkuil+cisco@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
/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