| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
On Wayland the video start path signalled any running wf-recorder with pkill -INT and then waited a fixed 0.1s before launching a new one. Releasing the compositor capture takes longer than that, so the new wf-recorder launched into a still-held grab, died immediately, and ffmpeg finalized a ~0.5-second fragment .mkv. Seeing nothing record, I'd press the key again and burst out a pile of fragments until the capture finally freed.
I replaced the fixed wait with a poll that waits until no wf-recorder remains (capped at 2s), the same move the stop path already made when it swapped its own fixed wait for cj/recording--wait-for-exit. Two supporting changes came with it. wf-recorder stderr no longer goes to /dev/null, so a failed grab shows up in the process buffer. And the sentinel now tells a ~0.5s failed start from a real stop, saying "failed to start, try again" instead of silently clearing, so one failure doesn't snowball into a blind-retry burst.
The poll and the fail-fast timing are unit-tested. The live capture needs a manual check.
|
| |
|
|
|
|
|
|
| |
Re-enabling native-comp surfaced a suite-wide fragility. When a test redefines a C primitive (or a native-compiled function), native-comp routes native callers through a trampoline that calls the mock with the primitive's maximum arity. A fixed-arity mock narrower than the primitive then throws wrong-number-of-arguments, intermittently, as the eln-cache fills.
I swept every arity-narrow subr mock to append &rest _ (188 sites, preserving any named args the body uses), and added tests/test-meta-subr-mock-arity.el, which fails make test on any subr mock too narrow for the primitive's arity. The rule isn't "never mock a subr". The suite mocks message and completing-read freely. It's "a subr mock must accept the primitive's arity."
Background, the three failure modes, and the research are in docs/native-comp-subr-mocking.org.
|
| |
|
|
|
|
| |
The X11 video path and the audio path interpolated the mic device, system device, and output filename straight into the shell command, so a device name or recording directory with a space (or other shell metacharacter) would break the command or mishandle the path. The Wayland video branch already quoted these; the other two did not.
I wrapped all three in shell-quote-argument on both paths. To make the audio command testable, I extracted it into cj/recording--build-audio-command mirroring the existing cj/recording--build-video-command, then quoted there. Tests cover device names and filenames with spaces on both the X11 and audio builders.
|
|
|
Cover build-video-command (9 tests), select-from-labeled (5 tests),
and test-device (4 tests). All three were previously tested only
indirectly through their callers.
|
