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