[Bug]: OpenScreen crashes when starting a recording on Ubuntu 24.04 #1340

Activity

1. PyVoyager

   added

   bugSomething isn't workingSomething isn't working

   on Oct 18, 2026
2. EtienneLescot commented on Oct 19, 2026

   

   EtienneLescot

   on Oct 19, 2026

   Member

   More actions

   Thanks for the report. The libavcodec crash in avcodec_open2 is a lead, but your report says both Ubuntu 24.04 and 22.04: which one is it? Could you also send the Mesa version, the output of vainfo, the lines of the terminal output containing capture-linux after the crash, and a Save Diagnostics file if the app still opens? That tells us which encoder it tried to open.
3. PyVoyager commented on Oct 24, 2026

   

   PyVoyager

   on Oct 24, 2026

   Author

   More actions

   Sorry for the delay. The OS is Ubuntu 24.04.5 LTS (22.04 was my mistake).

   I updated to 2.1.2. Now recording never starts: I select "Entire Screen" in the GNOME Share Screen dialog and click Share, and after 1–2 seconds OpenScreen shows "Error: The screen capture request was cancelled." So I can't reach the old libavcodec crash anymore.

   System:

   • Ubuntu 24.04.5, GNOME 46, X11 session
   • xdg-desktop-portal-gnome 46.2
   • AMD Radeon R5 (carrizo), Mesa 25.2.8
   • vainfo: H.264 encode supported (VAEntrypointEncSlice), HEVC decode only

   Log:

   [capture-linux] click-capture-unavailable: no readable /dev/input pointer device ...
   [capture-linux] click-capture-unavailable: no readable /dev/input pointer device ...
   [capture-linux] portal-cancelled: The screen capture request was cancelled.
   Could not prepare the native Linux capture: Error: The screen capture request was cancelled.
   [native-linux] starting capture { prepared: false, cursor: { mode: 'editable-overlay' }, video: { fps: 60 } }
   [capture-linux] portal-cancelled: The screen capture request was cancelled.
   Failed to start native Linux recording: Error: The screen capture request was cancelled.
   

   The portal itself works: calling the ScreenCast portal directly (CreateSession -> SelectSources -> Start) with the same options (types=1, cursor_mode=4, persist_mode=2) and clicking Share returns a stream normally.

   Two "click-capture-unavailable" lines appear before the first cancel, so maybe two capture sessions are started at once.

   Save Diagnostics is not attached: the app hangs after the error.
4. marcscama commented on Oct 25, 2026

   

   marcscama

   on Oct 25, 2026

   Last edited by marcscama

   More actions

   I confirm a similar bug with X11 with Debian Sid KDE! Wayland works.
5. EtienneLescot commented on Oct 28, 2026

   

   EtienneLescot

   on Oct 28, 2026

   Member

   More actions

   Thanks @PyVoyager, your log was the key: the two click-capture-unavailable lines do mean two capture sessions. A second Record press while the GNOME picker is open started a second one, and the two discarded each other's grant, so prepared: false followed your Share. #1413 ignores that second press.

   One question to confirm it is your case: did the picker take a moment to show, or open behind another window, so that Record got pressed again? If you saw only one dialog and pressed once, the X11 portal itself is at fault and #1328's direct X11 capture is the way. @marcscama, same question on KDE X11.
6. EtienneLescot

   added a commit that references this issue on Oct 28, 2026

   fix(linux): ignore a second record press while the portal picker is up

   ...

   1b86183
7. marcscama commented on Oct 28, 2026

   

   marcscama

   on Oct 28, 2026

   More actions

   Thanks. Not the double-press case on my side: I pressed Record once, and no picker dialog appeared at all. So it’s the second case, the X11 portal itself is at fault.

   Debian sid, KDE Plasma on X11 (kwin_x11), xdg-desktop-portal 1.20.4, xdg-desktop-portal-kde 6.6.5, OpenScreen 2.1.2 (.deb).

   In my diagnostic the two failures are sequential, not overlapping: prepare (CreateSession fails), then start ~3 s later after the countdown (fails again), each within ~50 ms, with portal-failed: CreateSession: Portal request didn't succeed: Other (not portal-cancelled). The portal journal says each time:
   xdp-kde-screencast: zkde_screencast_unstable_v1 does not seem to be available
   KWin only exposes that protocol on Wayland (known KDE limitation: https://bugs.kde.org/show_bug.cgi?id=454985). Wayland works for me.

   One caveat for #1328: on KDE X11 org.freedesktop.portal.ScreenCast is on the bus (busctl --user introspect org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop lists it), only CreateSession fails. A check based on the interface being absent (the Xfce case) wouldn’t select direct X11 capture here, so it should also cover a failing CreateSession.

   Happy to test a #1328 build on KDE X11.
8. PyVoyager commented on Nov 4, 2026

   

   PyVoyager

   on Nov 4, 2026

   Author

   More actions

   Update after testing 2.2.0 & 2.2.1 (Resolved + Root Causes & Branch with Fixes)

   Thanks @getopenscreen! I updated to 2.2.0 / 2.2.1 and tested on Ubuntu 24.04.5 LTS (GNOME 46, X11 session, hybrid GPU laptop: integrated AMD Radeon R5 Graphics (Carrizo) /dev/dri/renderD128 + discrete AMD Radeon R7 M340 (Topaz/Iceland) /dev/dri/renderD129).

   Everything is now working smoothly on my machine! We also prepared a clean branch with all the fixes applied directly to the TypeScript/Rust/C sources in case you'd like to cherry-pick or reference them:
   👉 Branch / Commit: PyVoyager@2a7feb2b (fix/linux-x11-hud-and-vaapi)

   Here is a summary of what was fixed upstream and the remaining Linux/Ubuntu 24.04 issues we diagnosed and fixed:

   ---

   1. ScreenCast Portal issue is fixed (PR #1413 confirmed)

   • The double-session / portal-cancelled problem is completely resolved in 2.2.0+.
   • The GNOME ScreenCast dialog opens once, and clicking Share immediately negotiates the PipeWire stream:

     [capture-linux] portal-stream-started: PipeWire node: 73
     [capture-linux] portal-open: state: streaming, fd: 48, node: 73
     

   ---

   2. VA-API skipped on Ubuntu 24.04 (vaMapBuffer2 check) + h264_vulkan SIGSEGV

   When capture starts out of the box on Ubuntu 24.04, the helper skips VA-API and crashes with SIGSEGV in libavcodec.so.62:

   1. Why VA-API is skipped on Ubuntu 24.04 LTS:
      vaapi_is_safe_to_probe() in electron/native/pipewire-capture/src/encoder.rs checks dlsym(libva, "vaMapBuffer2") because the vendored FFmpeg 8.1 (implib-gen in libavutil.so.60) resolves vaMapBuffer2 (added in libva 2.22).
      However, Ubuntu 24.04 LTS ships libva.so.2 2.20.0 (VA-API 1.20.0), which only exports vaMapBuffer(dpy, buf_id, pbuf) and not vaMapBuffer2. So VA-API is rejected even though the GPU driver (radeonsi_drv_video.so) supports VAProfileH264Main / VAProfileH264High (VAEntrypointEncSlice).
   2. Why h264_vulkan crashes with SIGSEGV:
      After skipping VA-API, the helper tries h264_vulkan. The GPU does not support Vulkan video encoding ([h264_vulkan] Encoding of h264 is not supported by this device), and FFmpeg hits a null-pointer dereference (SIGSEGV) during cleanup of the failed Vulkan encoder context before it can fall back to libopenh264.
   3. Clean Fix for VA-API on Ubuntu 24.04 (libva < 2.22):
      In electron/native/pipewire-capture/csrc/ffmpeg_accessors.c (with -Wl,--export-dynamic in build.rs), we added a dlsym compatibility fallback: when libavutil.so.60 requests "vaMapBuffer2" and the system libva.so.2 only exports vaMapBuffer, it returns a thin wrapper forwarding vaMapBuffer2(dpy, buf_id, pbuf, flags) to vaMapBuffer(dpy, buf_id, pbuf).
      With this in place (and vaapi_is_safe_to_probe() checking vaMapBuffer2 or vaMapBuffer), openscreen-pipewire-helper uses hardware h264_vaapi (H.264 High) on Ubuntu 24.04 out of the box with zero crashes!

   ---

   3. Hybrid GPUDRM Render Node Probing (/dev/dri/renderD128 .. renderD135)

   On laptops with an integrated APU (/dev/dri/renderD128) + a render-only mobile discrete GPU (/dev/dri/renderD129 AMD Radeon R7 M340 Iceland/Topaz, which physically lacks UVD/VCE hardware video blocks so vaInitialize fails on renderD129):

   • In electron/native/pipewire-capture/src/encoder.rs, electron/native/pipewire-capture/src/dmabuf_import.rs, and crates/compositor/src/pipeline_linux.rs, we updated the DRM/VA-API initialization to honor OPENSCREEN_LINUX_RENDER_NODE and automatically iterate across /dev/dri/renderD128..renderD135 until a render node that supports DRM + VA-API succeeds.
   • In electron/native-bridge/services/compositorViewService.ts, capping live preview readback dimensions on Linux (scaleLinuxPreviewRect, default max dimension 854, configurable via OPENSCREEN_LINUX_PREVIEW_MAX_DIM) reduces CPU ReadbackRing + Electron IPC bandwidth by 4× during timeline editing while keeping full 1080p/4K resolution on export.

   ---

   4. HUD Overlay Window Blocking Desktop Clicks & Popover Clipping on Linux X11

   • Root cause:
     1. In src/components/launch/LaunchWindow.tsx, setHudMouseEventsEnabled disables click-through on Linux (const shouldIgnoreMouseEvents = !enabled && !isLinuxHud), while measureHudSize permanently reserves stackMaxHeight: Math.max(popoverMaxHeight, modalMaxHeight) (470px) + HUD_GROWTH_RESERVE (120px). Under X11 (GNOME Mutter), that permanently expanded ~640×730 non-click-through window blocks mouse clicks across the center of the desktop.
     2. Furthermore, measureHudSize (useCallback(..., [trayLayout])) did not include isPopoverOpen in its dependencies, and on X11 hudOverlayWindow.setBounds(next, false) in electron/windows.ts is ignored by Mutter when resizable: false locks WM_NORMAL_HINTS min/max size.
   • Verified Fix:
     1. In src/components/launch/LaunchWindow.tsx, when on Linux and collapsed (!isPopoverOpen && trayLayout === "horizontal"), reserve only 86px above the bar (440×190 total window size — fits the bar and 4-line localized tooltips without covering the desktop), and include [trayLayout, isPopoverOpen, isLinuxHud] in measureHudSize so opening Settings (⚙️) or Language (RU) dynamically expands the window to ~640×730 and shrinks it back on close.
     2. In electron/windows.ts (setHudWindowBounds), temporarily toggle win.setResizable(true) around win.setBounds(next, false) and restore win.setResizable(false) on Linux X11 so the window manager honors the dynamic size change.