feat(linux): capture mouse clicks on Wayland via evdev

electron/native-bridge/cursor/recording/pipeWireCursorAccumulator.test.ts

@@ -56,13 +56,25 @@ describe("PipeWireCursorAccumulator", () => {
 		expect(point.timeMs).toBe(500);
 	});
 
-	it("reports every sample as a move, because Wayland exposes no buttons", () => {
+	it("defaults a sample with no interaction to a move", () => {
+		// The helper omits interactionType on the common case, so the accumulator
+		// owns the "move" fallback. This is what the user not being in the `input`
+		// group looks like: every sample arrives bare.
 		const accumulator = new PipeWireCursorAccumulator(100);
 		accumulator.reset(0);
 		accumulator.addSample(sample(10, 5, 5));
 		expect(accumulator.toRecordingData().samples[0].interactionType).toBe("move");
 	});
 
+	it("preserves a click the helper read from evdev", () => {
+		const accumulator = new PipeWireCursorAccumulator(100);
+		accumulator.reset(0);
+		accumulator.addSample(sample(10, 5, 5, { interactionType: "click" }));
+		accumulator.addSample(sample(20, 6, 6));
+		const { samples } = accumulator.toRecordingData();
+		expect(samples.map((s) => s.interactionType)).toEqual(["click", "move"]);
+	});
+
 	it("re-bases onto the video's start and drops what came before it", () => {
 		// This is the single-session case. Cursor samples start flowing as soon
 		// as the helper does, but the video's frame 0 is only stamped once the

electron/native-bridge/cursor/recording/pipeWireCursorAccumulator.ts

@@ -57,6 +57,11 @@ export type PipeWireHelperEvent =
 			visible: boolean;
 			assetId?: string;
 			asset?: PipeWireCursorAssetPayload;
+			/** `"click"` on the sample coinciding with a left-button press the
+			 *  helper read from evdev; absent on a plain move (see the helper's
+			 *  input.rs). The helper never emits the `"move"` default — that word
+			 *  is filled in below so it lives in exactly one place. */
+			interactionType?: "move" | "click";
 	  }
 	| {
 			event: "audio-source";
@@ -166,8 +171,10 @@ export class PipeWireCursorAccumulator {
 			cx: clamp(payload.x / width, 0, 1),
 			cy: clamp(payload.y / height, 0, 1),
 			visible: payload.visible,
-			// Wayland exposes no click events to an unprivileged process.
-			interactionType: "move",
+			// The portal never reports a button; the helper tags a sample "click"
+			// only when it read a left-button press from evdev (needs the user in
+			// the `input` group). Everything else — the common case — is a move.
+			interactionType: payload.interactionType ?? "move",
 			...(payload.assetId ? { assetId: payload.assetId } : {}),
 		});
 

electron/native-bridge/cursor/recording/pipeWireCursorRecordingSession.ts

@@ -21,8 +21,11 @@ import type { CursorRecordingSession } from "./session";
  *
  * Two consequences the caller should know about:
  *
- *   * `interactionType` is always "move". Wayland exposes no portal for mouse
- *     buttons and /dev/input/event* is root:input, so clicks are unobtainable.
+ *   * `interactionType` is "move" unless the helper could read left-button
+ *     presses from evdev — which needs the user in the `input` group, because
+ *     Wayland exposes no portal for mouse buttons and /dev/input/event* is
+ *     root:input. When it can, the coinciding sample is tagged "click"; when it
+ *     cannot, every sample is a move, as before. See the helper's input.rs.
  *   * The helper raises its own portal picker. On Wayland, Electron's
  *     `desktopCapturer` already raised one, so the user currently picks a source
  *     twice. Merging the two is the job of the capture stage that will reuse this

electron/native/README.md

@@ -89,8 +89,8 @@ Encoder selection: by default the helper keeps the existing sink-writer path fir
 
 Frame input path: the helper feeds the encoder from the GPU when it can. On that path it copies the WGC frame across a keyed-mutex bridge to a second D3D11 device, converts BGRA to NV12 with the D3D11 video processor, and submits an allocator-owned DXGI sample to the hardware H.264 encoder, so no frame ever passes through system memory. The alternative is the original path: a staging texture, `Map(D3D11_MAP_READ)`, and a row-by-row copy into an `IMFMediaBuffer` — which is where a driver stall costs a recording (issue #252). The GPU path is a preference, never a requirement: it is skipped outright for `preferSoftwareEncoder` and for inline webcam PiP (both need the frame in system memory), and it degrades to the CPU path on its own if the encoding device, the NV12 video processor, the shared bridge texture, the DXGI sample allocator, or the hardware sink writer is unavailable. The GPU path is OFF by default: it fixed #252 on the machine that reproduces it and broke recording outright in #336, and its fallbacks only cover failures during `initialize()`, not one that appears once frames are flowing. Set `OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1` to turn it on. Because the two paths land on different encoders and hardware MFTs default to constant bitrate, the GPU path asks for VBR through `ICodecAPI`; without it a static screen spends the full configured budget (measured 16.9 Mbps against 1.95 for the same desktop).
 
-The helper reports the outcome through the `encoder-selection` stdout event (`video` is `default`, `software-preferred`, or `software-fallback`; `videoInput` is `dxgi-nv12` or `cpu-rgb32`; `container` is `fragmented-mp4` or `mp4`; all three report what the encoder settled on rather than what was asked for). On the GPU path the helper also prints one `[frame-drops] gpu_bridge_contended=<n>` line to stderr at stop: a frame the bridge was too busy to take is skipped rather than failing the recording, and a large count there is the first thing to look at in a report about missing frames. When the app sees `software-fallback` — the default encoder failed and the helper switched on its own — it shows a small dismissible notice in the recording HUD with a "Don't show again" option, because software encoding can raise CPU usage. An explicit `software-preferred` selection shows no notice, and the event stays available for diagnostics either way.
-
+The helper reports the outcome through the `encoder-selection` stdout event (`video` is `default`, `software-preferred`, or `software-fallback`; `videoInput` is `dxgi-nv12` or `cpu-rgb32`; `container` is `fragmented-mp4` or `mp4`; all three report what the encoder settled on rather than what was asked for). On the GPU path the helper also prints one `[frame-drops] gpu_bridge_contended=<n>` line to stderr at stop: a frame the bridge was too busy to take is skipped rather than failing the recording, and a large count there is the first thing to look at in a report about missing frames. When the app sees `software-fallback` — the default encoder failed and the helper switched on its own — it shows a small dismissible notice in the recording HUD with a "Don't show again" option, because software encoding can raise CPU usage. An explicit `software-preferred` selection shows no notice, and the event stays available for diagnostics either way.
+
 At startup the helper also emits `capture-adapter`, naming the GPU its D3D device landed on and the one actually driving the captured display, each with its LUID, plus one `[adapters]` line per enumerated adapter on stderr. `createD3DDevice` asks for the *default* adapter and nothing checks that it is the one driving the display; when they differ every frame crosses an adapter boundary before the caller touches it. The LUIDs are there because the descriptions are not enough to tell: an IddCx virtual display driver renders through the physical GPU and inherits its description string while being a separate DXGI adapter, so the configuration this diagnostic exists to catch is precisely the one where both names are identical and only the LUIDs differ (measured: `NVIDIA Quadro RTX 4000` at LUID `0:24084` driving the display, the same string at `0:12889146` for the virtual adapter). `monitorLookup` says which of three things happened: `ok`, `no-output-claims-it` (the enumeration finished and nothing owns the captured monitor, which is what an active virtual display looks like), or `unavailable` (`EnumOutputs` refused, as it does in session 0 — the outputs were never inspected, so the absence means nothing about the hardware).
 
 Encoder diagnostic on final sink-writer failure: when the final sink-writer attempt fails (`MFCreateSinkWriterFromMediaSink` on the fragmented container, `MFCreateSinkWriterFromURL` on the plain one; the message names which), the helper logs the registered H.264 video encoder MFT count (via `MFTEnumEx`), the registered AAC encoder count when audio was requested, and the hex HRESULT. If no H.264 encoder is registered, it additionally emits the four-bullet actionable error (missing Media Feature Pack / GPU driver registration / empty `HKLM:\SOFTWARE\Microsoft\Windows Media Foundation\Transforms` / reboot). If an H.264 encoder IS registered but the sink writer still failed, it logs a hint pointing at invalid output path, missing MP4 mux, or GPU driver incompatibility. There is still no fail-fast pre-flight gate because `MFTEnumEx` and the sink writer can disagree about which H.264 encoders are available in non-interactive / Session 0 contexts.
@@ -209,9 +209,14 @@ electron/native/bin/linux-x64/openscreen-pipewire-helper '{"probeOnly":true}'
 
 ### Known gaps
 
-- **Mouse clicks are unobtainable.** Wayland exposes no portal for input events
-  and `/dev/input/event*` is `root:input`, so every sample's `interactionType` is
-  `"move"`.
+- **Mouse clicks need the `input` group.** Wayland exposes no portal for input
+  events, so the helper reads left-button presses straight from evdev
+  (`/dev/input/event*`). Those nodes are `root:input`, so a user outside the
+  `input` group gets no readable device and every sample's `interactionType`
+  stays `"move"` — the same as before. When a device is readable, the coinciding
+  sample is tagged `"click"`. Scope is deliberately narrow: `BTN_LEFT` only,
+  never keystrokes (see `pipewire-capture/src/input.rs`), and
+  `OPENSCREEN_DISABLE_CLICK_CAPTURE=1` turns it off entirely.
 - **The user picks a source twice.** Electron's `desktopCapturer` raises its own
   portal dialog for the video, and this helper raises a second one for the cursor.
   Collapsing them requires one portal session serving both, which is why the

electron/native/pipewire-capture/Cargo.toml

@@ -50,6 +50,7 @@ serde_json = "1"
 png = "0.17"
 base64 = "0.22"
 sha2 = "0.10"
+evdev = "0.13"
 
 [build-dependencies]
 cc = "1"

electron/native/pipewire-capture/src/events.rs

@@ -97,6 +97,12 @@ pub enum Event {
         asset_id: Option<String>,
         #[serde(skip_serializing_if = "Option::is_none")]
         asset: Option<CursorAsset>,
+        /// `"click"` on the sample that coincides with a left-button press read
+        /// from evdev (see `input.rs`), absent otherwise. Omitted rather than
+        /// defaulted to `"move"` so the accumulator keeps that fallback in one
+        /// place and the wire stays quiet on the common case.
+        #[serde(skip_serializing_if = "Option::is_none")]
+        interaction_type: Option<String>,
     },
     /// Which capture node each audio source was linked to.
     ///
@@ -303,12 +309,32 @@ mod tests {
             visible: true,
             asset_id: None,
             asset: None,
+            interaction_type: None,
         });
         assert_eq!(value["event"], "cursor-sample");
         assert_eq!(value["x"], 100);
         assert_eq!(value["visible"], true);
         assert!(value.get("assetId").is_none());
         assert!(value.get("asset").is_none());
+        // A plain move stays silent about its interaction so the accumulator's
+        // "move" default is the single source of that word.
+        assert!(value.get("interactionType").is_none());
+    }
+
+    #[test]
+    fn cursor_samples_report_a_click_when_tagged() {
+        let value = parse_one(&Event::CursorSample {
+            timestamp_ms: 12,
+            x: 100,
+            y: 200,
+            width: 1920,
+            height: 1080,
+            visible: true,
+            asset_id: None,
+            asset: None,
+            interaction_type: Some("click".to_owned()),
+        });
+        assert_eq!(value["interactionType"], "click");
     }
 
     #[test]
@@ -329,6 +355,7 @@ mod tests {
                 hotspot_x: 4,
                 hotspot_y: 3,
             }),
+            interaction_type: None,
         });
         assert_eq!(value["assetId"], "abc");
         assert_eq!(value["asset"]["imageDataUrl"], "data:image/png;base64,AA==");
@@ -359,6 +386,7 @@ mod tests {
             visible: true,
             asset_id: None,
             asset: None,
+            interaction_type: None,
         });
         assert_eq!(value["timestampMs"], 1234, "a sample's capture time must not be overwritten");
     }

electron/native/pipewire-capture/src/input.rs

@@ -0,0 +1,119 @@
+//! Left mouse-button telemetry on Wayland, read from evdev.
+//!
+//! WHY THIS EXISTS. Wayland deliberately denies an unprivileged process any view
+//! of global input: the ScreenCast portal reports cursor POSITION as frame
+//! metadata but never button state, and the only portal that streams input
+//! (`InputCapture`) *grabs* it, redirecting clicks away from the app being
+//! recorded — useless while the user is demoing. The one remaining source is the
+//! kernel's evdev interface (`/dev/input/event*`). Reading it needs membership in
+//! the `input` group (the nodes are `root:input`), which is the user's own,
+//! out-of-band act of consent — the Wayland equivalent of the button state the
+//! macOS and Windows helpers already read from their native APIs.
+//!
+//! SCOPE AND PRIVACY. A pointer node can also deliver keystrokes on a combined
+//! keyboard+mouse device. This reader inspects ONLY `EV_KEY` events whose code is
+//! `BTN_LEFT`, and only their press edge; it never reads, stores, or forwards any
+//! other key code, and it only ever opens devices that advertise `BTN_LEFT` in
+//! the first place. Set `OPENSCREEN_DISABLE_CLICK_CAPTURE=1` to turn it off
+//! entirely even where the permission exists.
+
+use std::sync::mpsc::Sender;
+use std::thread;
+
+use evdev::{Device, EventType, KeyCode};
+
+use crate::Message;
+
+const DISABLE_ENV: &str = "OPENSCREEN_DISABLE_CLICK_CAPTURE";
+
+/// True when this evdev event is the press edge of the left mouse button.
+///
+/// Extracted as a pure function so the decision is unit-testable without a real
+/// device: a release (`value == 0`), an autorepeat (`value == 2`), and every
+/// non-`BTN_LEFT` code — including every keyboard key — must NOT count.
+pub fn is_left_button_press(event_type: EventType, code: u16, value: i32) -> bool {
+    event_type == EventType::KEY && code == KeyCode::BTN_LEFT.0 && value == 1
+}
+
+/// Opens every readable pointer device that reports `BTN_LEFT` and spawns a
+/// reader thread per device. Returns whether at least one was opened — the caller
+/// uses that to tell the log why Linux clicks are or are not being captured.
+///
+/// Never fails: an unreadable node (the common case, when the user is not in the
+/// `input` group) is skipped by `evdev::enumerate`, and no readable node at all
+/// simply means every sample stays `"move"`, exactly as before this existed.
+pub fn spawn_readers(sender: &Sender<Message>) -> bool {
+    if std::env::var_os(DISABLE_ENV).is_some() {
+        return false;
+    }
+    let mut opened = 0usize;
+    for (_path, device) in evdev::enumerate() {
+        if !device_reports_left_button(&device) {
+            continue;
+        }
+        opened += 1;
+        let forward = sender.clone();
+        thread::spawn(move || read_device(device, forward));
+    }
+    opened > 0
+}
+
+fn device_reports_left_button(device: &Device) -> bool {
+    device
+        .supported_keys()
+        .is_some_and(|keys| keys.contains(KeyCode::BTN_LEFT))
+}
+
+/// Blocks reading `device`, forwarding one `PointerButton` message per left-button
+/// press. Returns when the device errors (e.g. unplugged) or the loop's channel
+/// has closed, so the thread cannot outlive the recording it serves.
+fn read_device(mut device: Device, sender: Sender<Message>) {
+    loop {
+        let events = match device.fetch_events() {
+            Ok(events) => events,
+            Err(_) => return,
+        };
+        for event in events {
+            if is_left_button_press(event.event_type(), event.code(), event.value())
+                && sender.send(Message::PointerButton).is_err()
+            {
+                return;
+            }
+        }
+    }
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    const BTN_LEFT: u16 = KeyCode::BTN_LEFT.0;
+    const BTN_RIGHT: u16 = KeyCode::BTN_RIGHT.0;
+
+    #[test]
+    fn a_left_button_press_is_a_click() {
+        assert!(is_left_button_press(EventType::KEY, BTN_LEFT, 1));
+    }
+
+    #[test]
+    fn a_left_button_release_is_not() {
+        assert!(!is_left_button_press(EventType::KEY, BTN_LEFT, 0));
+    }
+
+    #[test]
+    fn a_left_button_autorepeat_is_not() {
+        // A held button emits value 2; only the 0->1 edge is a click.
+        assert!(!is_left_button_press(EventType::KEY, BTN_LEFT, 2));
+    }
+
+    #[test]
+    fn a_right_button_press_is_not_a_left_click() {
+        assert!(!is_left_button_press(EventType::KEY, BTN_RIGHT, 1));
+    }
+
+    #[test]
+    fn a_key_matching_btn_lefts_code_on_another_axis_is_not_a_click() {
+        // Same numeric code but a relative-motion event, not a key — must miss.
+        assert!(!is_left_button_press(EventType::RELATIVE, BTN_LEFT, 1));
+    }
+}