Plugin: name the USB helper this platform actually needs - #120
Merged
Conversation
"No device detected on USB — check the cable and tap Trust (Windows also needs iTunes)" is a dead end for a Linux user, who has no iTunes to check and no hint that the transport speaks to a daemon at /var/run/usbmuxd which their distribution may not have installed. That is the one status line they see at the moment the answer matters. The usbmuxd protocol comes from somewhere different on each platform, so the status now names the right one per build: the Apple Mobile Device Service on Windows, the usbmuxd daemon on Linux, and neither on macOS, where it is part of the OS and there is nothing to suggest. The key is chosen at compile time beside the other platform notes, so no string mentions a system it cannot be read on. The base Status.WaitingUSB key keeps its name, so existing translations of it stay valid and become the macOS text. Both help strings gain the Linux half of the same sentence. Verified: builds clean on Linux with -Wall -Wextra -Werror; the module carries Status.WaitingUSB.Linux, confirming the intended branch; and every T_() key in the source resolves in en-US.ini. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA
Deploying lenslink with
|
| Latest commit: |
9f51ad8
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c7a0f6dc.lenslink.pages.dev |
| Branch Preview URL: | https://claude-usbmux-status-message.lenslink.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The status shown when USB finds nothing reads:
For a Linux user that's a dead end. There's no iTunes to check, and no hint
that
usbmux.cconnects to ausbmuxddaemon at/var/run/usbmuxdwhichtheir distribution may or may not have installed. It's the one line they see at
the moment the answer matters, and it names a fix that can't apply to them.
The usbmuxd protocol comes from somewhere different on each platform, so the
status now names the right one per build:
localhost:27015/var/run/usbmuxdThe key is selected at compile time, beside the other platform notes at the top
of the file, so no build ships a string mentioning a system it can't be read
on. All three also now mention a data cable rather than a charge-only one,
which is the other silent failure here.
Status.WaitingUSBkeeps its name and becomes the macOS text, so existingtranslations of it stay valid rather than being orphaned by a rename. Both help
strings gain the Linux half of the same sentence.
Follows the documentation fix in #119, which corrected the same omission on the
website and in the README.
How it was tested
-Wall -Wextra -Werror, matching CI.stringson the built module showsStatus.WaitingUSB.Linuxand not theother two, confirming the intended branch compiled.
T_()key inios-camera-source.cagainsten-US.ini— 41 keys, none missing.Not verified from here: the string as it appears in the OBS properties dialog,
and the Windows and macOS branches, which this container can't compile. The
selection is a three-way
#ifdefover a literal, so the risk is wording ratherthan behavior.
Releases
No release trailer, so merging cuts a patch release —
obs-plugin/is inthe release paths. That seems right for a user-facing fix, but add
Release-Skip: trueto a commit here if you'd rather batch it with the nextchange.
🤖 Generated with Claude Code
https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA
Generated by Claude Code