obsbot-mcp 0.4.0 → 0.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -225,14 +225,14 @@ make install # copies to native/prebuilt/linux-x64/
225
225
  ### Linux gimbal position feedback is not live
226
226
 
227
227
  `obsbot_gimbal_position` on Linux reports the last position `obsbot_gimbal_move`/
228
- `obsbot_gimbal_recenter` commanded — not a live, in-flight reading. This is a Linux kernel-driver
229
- gap, not a firmware limitation: hardware testing (2026-07-21) confirmed the OBSBOT Tiny 2's
230
- `CT_PANTILT_ABSOLUTE` control genuinely tracks live position — a raw USB read of that same control,
231
- bypassing the kernel, showed a real slew progressing in real time. The reason plain V4L2
232
- (`VIDIOC_G_CTRL`) never sees that is that `uvcvideo` doesn't mark `V4L2_CID_PAN_ABSOLUTE`/
233
- `TILT_ABSOLUTE` as `V4L2_CTRL_FLAG_VOLATILE` on this kernel (confirmed via `VIDIOC_QUERY_EXT_CTRL`),
234
- so the V4L2 core control framework serves its own cache of the last `VIDIOC_S_CTRL` value instead of
235
- re-querying the device.
228
+ `obsbot_gimbal_recenter` commanded — not a live, in-flight reading. Hardware testing (2026-07-21)
229
+ confirmed the OBSBOT Tiny 2's `CT_PANTILT_ABSOLUTE` control genuinely tracks live position — a raw
230
+ USB read of that same control, bypassing the kernel, showed a real slew progressing in real time.
231
+ The reason plain V4L2 (`VIDIOC_G_CTRL`) never sees that is that `uvcvideo` caches the control's
232
+ value and serves the cache instead of re-querying the device (confirmed via
233
+ `VIDIOC_QUERY_EXT_CTRL`, which reports no `V4L2_CTRL_FLAG_VOLATILE`). The driver invalidates that
234
+ cache when the device sends a UVC Control Change interrupt — which this camera's firmware never
235
+ does, and never advertises support for.
236
236
 
237
237
  Getting a genuinely live reading through V4L2 requires briefly detaching the kernel driver from
238
238
  the camera's control interface and reading the control directly over raw USB — but detaching that
@@ -241,10 +241,8 @@ device: streaming and control share one kernel-managed USB function, so pulling
241
241
  takes both down together. That makes a libusb-based workaround incompatible with anything actually
242
242
  using the camera as a webcam at the same time, which ruled it out as a shipped default.
243
243
 
244
- **A kernel patch has been submitted upstream** to mark these controls volatile in `uvcvideo`,
245
- matching precedent — this device already has one OBSBOT-specific quirk merged
246
- (`UVC_QUIRK_OBSBOT_MIN_SETTINGS`, a different bug). If it lands, `obsbot_gimbal_position` would
247
- become live through plain V4L2 with no code changes needed here. Until then:
244
+ **A kernel patch is being worked on.** If one lands, `obsbot_gimbal_position` would become live
245
+ through plain V4L2 with no code changes needed here. Until then:
248
246
 
249
247
  - `obsbot_gimbal_move` and `obsbot_gimbal_recenter` work normally — hardware-verified,
250
248
  repeatedly, via direct V4L2 `VIDIOC_S_CTRL` writes. Their target values are known and clamped
@@ -351,7 +349,7 @@ What has actually been exercised against hardware, and what hasn't:
351
349
  wasn't available). Single-camera use is unaffected either way.
352
350
  - **Linux gimbal position feedback is not live, and `obsbot_gimbal_move_speed` is unavailable
353
351
  there as a result.** See ["Linux gimbal position feedback is not live"](#linux-gimbal-position-feedback-is-not-live)
354
- above — a kernel patch has been submitted to fix this at the source. `obsbot_gimbal_move` and
352
+ above — a kernel patch to fix this at the source is being worked on. `obsbot_gimbal_move` and
355
353
  `obsbot_gimbal_recenter` are unaffected; both are hardware-verified to work normally.
356
354
  - **`obsbot_zoom_vendor`'s ratio scale doesn't match `obsbot_zoom_uvc`'s at the same `ratio`.** A
357
355
  hardware snapshot comparison at `ratio: 2.0` showed the vendor path framed tighter than the UVC
@@ -71,7 +71,7 @@ export async function startServer(opts = {}) {
71
71
  process.on("SIGTERM", () => { shutdown(); process.exit(0); });
72
72
  const server = new Server(
73
73
  // Must match package.json's version; test/version-sync.test.ts enforces it.
74
- { name: "obsbot-mcp", version: "0.4.0" }, { capabilities: { tools: {} } });
74
+ { name: "obsbot-mcp", version: "0.4.1" }, { capabilities: { tools: {} } });
75
75
  server.setRequestHandler(ListToolsRequestSchema, async () => ({
76
76
  tools: tools.map((tool) => ({
77
77
  name: tool.name,
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "obsbot-mcp",
3
- "version": "0.4.0",
3
+ "version": "0.4.1",
4
4
  "description": "Cross-platform MCP server for OBSBOT Tiny 2 (UVC) camera control",
5
5
  "license": "MIT",
6
6
  "author": "Michael Jordan",