Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#1,244 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
12/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c, linux

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
TypeScript
Étoiles
3.7k
Forks
231
Merge moyen
15 h 10 min
PR mergées (30 j)
324

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getopenscreen/openscreen

Toutes les issues de getopenscreen/openscreen

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.