Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#1,244 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, linux

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
TypeScript
Estrellas
3.7k
Forks
231
Merge medio
16 h 38 min
PR fusionados (30 d)
327

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getopenscreen/openscreen

Todos los issues de getopenscreen/openscreen

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.