[Bug]: No frames on niri + NVIDIA: niri allocates the screencast dmabuf with the INVALID modifier and cannot render into it
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
- Domaine
- audio-video-rtc, desktop-dev
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
- Run niri 26.04 with xdg-desktop-portal-gnome as the ScreenCast backend (
AvailableCursorModes=7) and an NVIDIA RTX 4070 as the only GPU. - Open OpenScreen 2.0.0, click record and pick a monitor in the portal dialog.
- 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 AURopenscreen) - 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
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de getopenscreen/openscreen
-
Native review wanted: machine-translated recording bar tooltips (14 locales)Peut-être à nouveau libre @auberginewly l’a pris il y a 21 jours, et aucune pull request n’est ouverte. Ouvertegood first issue help wanted
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
getopenscreen/openscreen#913 · 5 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
[Bug]: Windows update click opens the full NSIS wizard instead of a UAC promptPeut-être pris @EtienneLescot l’a pris aujourd’hui. Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 30/100
getopenscreen/openscreen#1437 ·
Les mainteneurs répondent en général sous 1 jour
-
[Feature]: Cursor size px unitOuverteenhancement
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
getopenscreen/openscreen#1436 ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
getopenscreen/openscreen#1435 ·
Les mainteneurs répondent en général sous 1 jour
-
QA: e2e pass on v2.2.0-rc.1 (macOS, Windows)Peut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 55/100
getopenscreen/openscreen#1431 · 4 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de getopenscreen/openscreen
Issues similaires
-
Replace discontinued crypto-js in the themePeut-être pris @aelmanaa l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
PaloAltoNetworks/docusaurus-openapi-docs#1689 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
solana-foundation/solana-web3.js#4015 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
formatSearchQuery drops the :present modifier, so `email:present=true` is sent as `email=true`Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
documentation
Difficulté 1/5 1-3 heures Accessibilité débutants 90/100
ivopogace/opencode-courier#422 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
chapel-lang/chapel-vscode#158 ·
Les mainteneurs répondent en général sous 1 jour