Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Bug]: No frames on niri + NVIDIA: niri allocates the screencast dmabuf with the INVALID modifier and cannot render into it

Offen
#1,244 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
12/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
c, linux

Rechercherichtung

Start with the DMA-BUF format negotiation: osc_build_enum_format_dmabuf in the PipeWire capture code, and pw_shim.c where niri's buffers are handled. Run with OPENSCREEN_PIPEWIRE_DEBUG=1 to see the modifier the compositor picks and the producer-marked-corrupted drops. Done means frames arrive on NVIDIA with a renderable modifier, verified by a recording with cursor metadata.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Search existing issues
  • I have searched the existing issues (related but different: #324, #287, #92)
Describe the bug

On niri with an NVIDIA GPU, recording never produces a video. The portal session and the PipeWire stream start, and cursor metadata arrives, but the compositor marks every video buffer as corrupted, so every frame is dropped before it reaches the encoder.

niri only produces screencast buffers as DMA-BUF (no memfd path, as noted in pw_shim.c for #287). On this machine the VAAPI import probe fails (dmabuf-import available:false, [AVHWFramesContext] Unsupported format: bgr0). As a result, osc_build_enum_format_dmabuf advertises only LINEAR and INVALID. niri narrows that to modifiers=[INVALID] and allocates the buffer with an implicit modifier, which the NVIDIA EGL driver cannot bind as a render target.

niri log:

find_preferred_modifier: size=1920x1080, fourcc=XR24, modifiers=[72057594037927935]
allocation successful (modifier=Invalid, plane_count=1), moving to ready
ERROR smithay::backend::renderer::gles: [GL] GL_INVALID_OPERATION error generated. EGLImage not supported
WARN niri::screencasting::pw_utils: error rendering to dmabuf: error binding dmabuf

OpenScreen log (OPENSCREEN_PIPEWIRE_DEBUG=1):

[capture-linux][debug] {"available":false,"code":"dmabuf-import",...}
[capture-linux] [osc-dmabuf] negotiated 1920x1080 uses_dmabuf=1 modifier=0xffffffffffffff
[capture-linux] [osc-frame-drop] reason=producer-marked-frame-corrupted data_type=DmaBuf chunk_size=0 chunk_flags=1 stride=7680 width=1920 height=1080 format=8
[capture-linux][debug] {"code":"buffer-info","dataType":"DmaBuf","hasCursorMeta":true,"metas":"Busy:8,Header:32,Cursor:589872",...}

OPENSCREEN_LINUX_ENCODER=vulkan gives the same result: shm is offered first, but niri still negotiates the DMA-BUF object.

On the same machine, Chromium/Electron capture through the same portal works. It advertises NVIDIA tiled modifiers, and niri allocates with 0x300000000e08014 and renders without errors. So niri can deliver frames when a renderable modifier is offered.

A possible fix: on NVIDIA, advertise the EGL-importable tiled modifiers even when the VAAPI probe fails, and import them through EGL/Vulkan instead of mmap.

Expected behavior

Recording a monitor produces a video with cursor telemetry, as it does on GNOME and KDE.

To Reproduce
  1. Run niri 26.04 with xdg-desktop-portal-gnome as the ScreenCast backend (AvailableCursorModes=7) and an NVIDIA RTX 4070 as the only GPU.
  2. Open OpenScreen 2.0.0, click record and pick a monitor in the portal dialog.
  3. Nothing is recorded, and the log lines above repeat for every frame.
Environment
  • OS: Linux (CachyOS), kernel 7.2.9-2-cachyos
  • OpenScreen 2.0.0 (official Openscreen-Linux-2.0.0.pacman, through AUR openscreen)
  • niri 26.04 (8ed0da4), PipeWire 1.6.9, xdg-desktop-portal 1.22.1, xdg-desktop-portal-gnome 51.0
  • NVIDIA GeForce RTX 4070, open kernel module 615.78.08, libva-nvidia-driver 0.0.18, FFmpeg 9.0.2
Vorherrschende Sprache
TypeScript
Sterne
3.7k
Forks
231
Ø Merge
16 Std. 38 Min.
Gemergte PRs (30 T.)
327

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus getopenscreen/openscreen

Alle Issues in getopenscreen/openscreen

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.