feat(call): Linux camera send + cross-platform camera CI verification - #35
Merged
Conversation
added 2 commits
July 26, 2026 02:53
…ust macOS) Groundwork for non-macOS camera send. The camera backend (ras-camera --features capture) was compile-checked on macOS only; its Linux V4L2 / Windows Media Foundation builds were unverified. Prove they build in CI before wiring the camera into the app on those platforms (the app isn't compiled in push-CI, so an unverified camera dep would otherwise only fail at release). - Add libv4l-dev to the Linux capture deps (v4l2-sys-mit needs linux/videodev2.h; can't be built on the macOS dev machine). - Run the ras-camera capture compile-check on all three OSes. Purely additive — only adds CI coverage; cannot affect existing builds. Author: sachin sarwa
Builds on the camera compile-check groundwork: now that CI proves the nokhwa backend builds on all three OSes, wire the camera into the app's Share/Call role on Linux (macOS already sends; every platform already receives + renders). - app: add ras-camera (features=capture) to the Linux target deps; widen the camera egress + pump cfg from macOS-only to any(macos, linux). Linux uses the same VP9 encoder (ras-media-vpx, already a proven Linux dep) macOS uses for the camera — universally WebCodecs-decodable, so a Linux caller's camera renders on every peer. Windows camera send stays deferred (no libvpx there — needs a codec decision); Windows still receives video and sends voice. - ci: new "app compile-check (linux)" job — full cargo check of the app on ubuntu-22.04 with all native deps (WebKitGTK, PipeWire/Pulse, ALSA, V4L2, libvpx). The app is outside the workspace and was previously built ONLY at release, so an app-level Linux regression surfaced at release, not push-CI. This closes that gap for the camera path and every future app change. - ci: the nokhwa camera compile-check now runs on Linux + Windows too (was macOS-only) + libv4l-dev added to the Linux capture deps. Security unchanged (Inv 8/12): camera live-only, torn down on hangup, no pixel logged. Verified: app cargo check + clippy + fmt on macOS; CI now compiles the app on Linux and the camera backend on all three OSes. On-device (a real Linux camera call) pending hardware. Author: sachin sarwa
schnsrw
changed the title
…nux build broke) The new Linux app compile-check surfaced a pre-existing broken lockfile: the app Cargo.lock had zbus 5.12.0 paired with zbus_macros 5.18.0. zbus pins its macros with a caret, and zbus 5.18.0 is held back by ras-input-linux's rustix "=1.0.8", so the lib stayed at 5.12.0 while the proc-macro floated to 5.18.0 — whose generated code references object_server::DispatchResult2, absent in 5.12.0 (E0433). Never caught before because push-CI never compiled the Linux app. Pin zbus_macros back to 5.12.0 to match the lib (no rustix conflict, unlike bumping zbus up). zbus/zvariant families are otherwise internally consistent. Author: sachin sarwa
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
1 participant
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.
Non-macOS camera send for video calls, done on verified ground. Before writing camera code I confirmed the hard constraint: the Linux camera backend (
v4l2-sys-mit) bindgens againstlinux/videodev2.h, which isn't on the macOS dev machine — so a Linux camera build can't be verified locally, and push-CI didn't compile the app at all (only a license gate). This PR fixes the verification path first, then wires the feature.CI (verification first)
libv4l-devto the Linux capture deps. (This half is already green — see the checks.)app compile-check (linux)job — a fullcargo checkof the unified app on ubuntu-22.04 with all native deps (WebKitGTK, PipeWire/Pulse, ALSA mic, V4L2 camera, libvpx VP9). The app lives outside the workspace and was previously built only at release, so an app-level Linux regression surfaced at release, not in push-CI. This closes that gap for the camera path and every future app change.Feature
ras-camera(features=capture) to the Linux app deps; widen the camera egress + pumpcfgfrom macOS-only toany(macos, linux).ras-media-vpx, already a proven Linux dep) macOS uses for the camera — universally WebCodecs-decodable, so a Linux caller's camera renders on every peer.Security (unchanged)
Camera live-only, torn down on hangup/emergency-stop (Inv 4/12); no pixel logged (Inv 8).
Verification
App
cargo check+clippy+fmton macOS; CI now compiles the app on Linux and the camera backend on all three OSes. On-device (a real Linux camera call) pending hardware.