linux, sway, wlr capture fails on Intel due to stride mismatch (Yf-tiled)

Abierto
  • ¿Algo no está bien?
#5,571 0 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp, linux
Área
desktop-dev, operating-systems

Línea de trabajo

Usa la traza de protocolo Wayland proporcionada como punto de partida y sigue la ruta de captura de wlroots que gestiona el evento .buffer() del compositor y construye la llamada add de linux-dmabuf. Compara el stride anunciado de 10944 con el stride asignado de 11008 y verifica después en la configuración Intel/Sway indicada que wlr capture funciona correctamente sin fallos repetidos de captura de frames.

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

Descripción

Is there an existing issue for this?
  • I have searched the existing issues
Is your issue described in the documentation?
  • I have read the documentation
Is your issue present in the latest beta/pre-release?

No response

Describe the Bug

Environment

  • OS: Debian testing
  • Compositor: Sway 1.12 (wlroots 0.20)
  • GPU: Intel Kaby Lake (HD 620) - Surface Pro 5
  • Driver: intel-media-va-driver 26.1.6 (iHD)
  • Sunshine version: 2026.826.1804 (commit f273ce8f45db0bd6c7810a0f2c77e170f1a40f6e)
  • Display: Physical screen, eDP-1, 2736x1824

Problem

Sunshine fails to capture screen via wlr-screencopy protocol with repeated [wayland] Frame capture failed errors. The compositor consistently rejects the screencopy request with zwlr_screencopy_frame_v1.failed().

KMS capture works fine. Other tools using the same protocol (grim, wl-screenrec) work successfully on the same system.

Root cause (from Wayland protocol trace)

Stride mismatch between what the compositor advertises and what Sunshine allocates:

Compositor advertises: 
  zwlr_screencopy_frame_v1.buffer(875709016, 2736, 1824, 10944)
                                  ^^^^^^^^^ XR24 format    ^^^^^ stride

Sunshine allocates:
  zwp_linux_buffer_params_v1.add(fd, 0, 0, 11008, 16777216, 4)
                                          ^^^^^ stride (should be 10944)
                                          ^^^^^^^^^^^^^^^^^ modifier: Intel Yf-tiled

Compositor response:
  zwlr_screencopy_frame_v1.failed()

Sunshine calculates stride as 11008 (64 bytes more than required), while the compositor expects exactly 10944 bytes (2736 pixels × 4 bytes/pixel). With Intel Yf-tiled modifier, wlroots strictly enforces stride alignment and rejects the mismatch.

Expected behavior

Sunshine should use the stride value provided by the compositor in the .buffer() event, not calculate its own.

Verification

Tools that work correctly (wl-screenrec) use stride 10944 in their .add() call, matching the compositor's .buffer() event.

Workaround

Setting capture = kms in sunshine.conf works as a temporary solution.

Full protocol trace excerpt

Click to expand 
[ 298465.311] {Default Queue} zwlr_screencopy_frame_v1#8.buffer(875709016, 2736, 1824, 10944)
[ 298465.319] {Default Queue} zwlr_screencopy_frame_v1#8.linux_dmabuf(875713112, 2736, 1824)
[ 298465.323] {Default Queue} zwlr_screencopy_frame_v1#8.buffer_done()
[ 298473.915] {Default Queue}  -> zwp_linux_dmabuf_v1#4.create_params(new id zwp_linux_buffer_params_v1#9)
[ 298473.933] {Default Queue}  -> zwp_linux_buffer_params_v1#9.add(fd 57, 0, 0, 11008, 16777216, 4)
[ 298473.938] {Default Queue}  -> zwp_linux_buffer_params_v1#9.create(2736, 1824, 875713112, 0)
[ 298474.033] {Default Queue} zwp_linux_buffer_params_v1#9.created(new id wl_buffer#4278190080)
[ 298474.042] {Default Queue}  -> zwp_linux_buffer_params_v1#9.destroy()
[ 298474.045] {Default Queue}  -> zwlr_screencopy_frame_v1#8.copy(wl_buffer#4278190080)
[ 298486.899] {Default Queue} zwlr_screencopy_frame_v1#8.failed()

This pattern repeats consistently on every capture attempt.

Expected Behavior

No response

Additional Context

No response

Host Operating System

Linux

Operating System Version

debian testing

Architecture

amd64/x86_64

Package

Linux - deb

GPU Type

Intel

GPU Model

Kaby Lake (HD 620)

GPU Driver/Mesa Version

intel-media-va-driver 26.1.6

Capture Method

wlroots (FreeBSD/Linux)

Apps
Log output
Online logs

No response

Lenguaje dominante
C++
Estrellas
43k
Forks
2.4k
Merge medio
1 d 15 h
PR fusionados (30 d)
105

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 LizardByte/Sunshine

Todos los issues de LizardByte/Sunshine

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.