The Platform differences table in website/docs/installation.md still describes the
pre-native Linux capture path, and now contradicts the prose directly above it.
Raised from a CodeRabbit review comment on #501
(#501 (comment)), verified
against main after that PR merged, and extended with a second stale row found while
hardware-validating #508.
1. Capture pipeline says Linux is the browser pipeline
| Capture pipeline | Native (ScreenCaptureKit) | Native (Windows Graphics Capture) | Browser pipeline |
Linux has had a native PipeWire capture helper for a while: it records video + audio and
muxes MP4 (H.264 + AAC) directly. getDisplayMedia/MediaRecorder is only the
fallback when the helper is missing. The row reads as though the browser path were
still the norm, and it contradicts the "Mouse clicks on Wayland" section a few lines
above, which describes the native helper reading evdev.
2. MP4 export says software encode
| MP4 export | ✅ | ✅ | ✅ (software encode) |
Stale since #508. The helper's encoder ladder prefers h264_vaapi, and on the dmabuf
zero-copy path the encoder is opened directly against the importer's VAAPI surface pool.
Measured on AMD Mendocino (Radeon 610M, Mesa 25.2.8, GNOME/Wayland), whole-monitor
capture, no env overrides:
{"event":"encoder-selection","rejected":[],"video":"vaapi"}
{"convertMs":0.0,"uploadMs":0.0000392,"encodeMs":0.467,"frames":7258,"dropped":0}
Software encode is the last rung of the ladder, not the Linux default. The row should say
hardware where available (VAAPI, then Vulkan) with a software fallback.
3. Note: one row the review comment flagged is already correct
The review comment also claimed the table says Linux "has no custom cursor click effects".
That row was already updated by #501 and currently reads:
| Custom cursor themes / click effects | ✅ | ✅ | ✅ on Wayland — click capture needs the `input` group ([details](#mouse-clicks-on-wayland)) |
No change needed there — flagging it so the fix does not "correct" a row that is already
accurate.
Scope
Documentation only, two rows in one table. Worth a pass over the remaining Linux cells at
the same time (Webcam still says "Browser capture") to confirm which of them still
reflect reality.
The Platform differences table in
website/docs/installation.mdstill describes thepre-native Linux capture path, and now contradicts the prose directly above it.
Raised from a CodeRabbit review comment on #501
(#501 (comment)), verified
against
mainafter that PR merged, and extended with a second stale row found whilehardware-validating #508.
1.
Capture pipelinesays Linux is the browser pipelineLinux has had a native PipeWire capture helper for a while: it records video + audio and
muxes MP4 (H.264 + AAC) directly.
getDisplayMedia/MediaRecorderis only thefallback when the helper is missing. The row reads as though the browser path were
still the norm, and it contradicts the "Mouse clicks on Wayland" section a few lines
above, which describes the native helper reading evdev.
2.
MP4 exportsays software encodeStale since #508. The helper's encoder ladder prefers
h264_vaapi, and on the dmabufzero-copy path the encoder is opened directly against the importer's VAAPI surface pool.
Measured on AMD Mendocino (Radeon 610M, Mesa 25.2.8, GNOME/Wayland), whole-monitor
capture, no env overrides:
Software encode is the last rung of the ladder, not the Linux default. The row should say
hardware where available (VAAPI, then Vulkan) with a software fallback.
3. Note: one row the review comment flagged is already correct
The review comment also claimed the table says Linux "has no custom cursor click effects".
That row was already updated by #501 and currently reads:
No change needed there — flagging it so the fix does not "correct" a row that is already
accurate.
Scope
Documentation only, two rows in one table. Worth a pass over the remaining Linux cells at
the same time (
Webcamstill says "Browser capture") to confirm which of them stillreflect reality.