Portal grab not functional after pipewire upgrade to 1.6.0

[neatnoise]

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?

This issue is present in the latest pre-release

Describe the Bug

After the upgrade of pipewire from 1.4.10 to 1.6.0 portal grab isn't functional. It seems that pipewire input formats have changed in 1.6.0. After client connects there is black and green screen.

Latest CachyOS KDE, AMD GPU 9070 XT

mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.817]: Info: Loaded portal restore token from disk
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.817]: Info: Screencasting with XDG portal
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.817]: Info: Requested frame rate [60fps]
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.817]: Info: Found display [wayland-0]
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.826]: Info: Loaded portal restore token from disk
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.828]: Error: SelectDevices failed with response code: 2
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.829]: Warning: RemoteDesktop.SelectDevices failed, falling back to ScreenCast-only mode
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.843]: Info: Connected to pipewire version 1.6.0
mar 06 14:41:28 sunshine[8806]: [2026-03-06 14:41:28.846]: Info: Pipewire Error, id:2 seq:16 message: no more input formats

Expected Behavior

Portal grab starts

Additional Context

No response

Host Operating System

Linux

Operating System Version

CachyOS latest

Architecture

amd64/x86_64

Package

Linux - AUR (Third Party)

GPU Type

AMD

GPU Model

9070 XT

GPU Driver/Mesa Version

26.1

Capture Method

XDG Portal Grab (Linux)

Apps

Log output

Online logs

No response

[solidv]

Can confirm this. Downgrading to 1.4.10 fixed.

[neatnoise]

diff --git a/src/platform/linux/portalgrab.cpp b/src/platform/linux/portalgrab.cpp
index 17a56721..xxxxxxxx 100644
--- a/src/platform/linux/portalgrab.cpp
+++ b/src/platform/linux/portalgrab.cpp
@@ -935,17 +935,15 @@ namespace portal {
       sizes[1] = SPA_RECTANGLE(1, 1);
       sizes[2] = SPA_RECTANGLE(8192, 4096);
 
-      framerates[0] = SPA_FRACTION(0, 1);  // we only want variable rate, thus bypassing compositor pacing
-      framerates[1] = SPA_FRACTION(0, 1);
-      framerates[2] = SPA_FRACTION(0, 1);
+      framerates[0] = SPA_FRACTION(0, 1);  // variable rate capture
 
       spa_pod_builder_push_object(b, &object_frame, SPA_TYPE_OBJECT_Format, SPA_PARAM_EnumFormat);
       spa_pod_builder_add(b, SPA_FORMAT_mediaType, SPA_POD_Id(SPA_MEDIA_TYPE_video), 0);
       spa_pod_builder_add(b, SPA_FORMAT_mediaSubtype, SPA_POD_Id(SPA_MEDIA_SUBTYPE_raw), 0);
       spa_pod_builder_add(b, SPA_FORMAT_VIDEO_format, SPA_POD_Id(format), 0);
       spa_pod_builder_add(b, SPA_FORMAT_VIDEO_size, SPA_POD_CHOICE_RANGE_Rectangle(&sizes[0], &sizes[1], &sizes[2]), 0);
-      spa_pod_builder_add(b, SPA_FORMAT_VIDEO_framerate, SPA_POD_CHOICE_RANGE_Fraction(&framerates[0], &framerates[1], &framerates[2]), 0);
-      spa_pod_builder_add(b, SPA_FORMAT_VIDEO_maxFramerate, SPA_POD_CHOICE_RANGE_Fraction(&framerates[0], &framerates[1], &framerates[2]), 0);
+      spa_pod_builder_add(b, SPA_FORMAT_VIDEO_framerate, SPA_POD_Fraction(&framerates[0]), 0);

This makes the client to connect, but the FPS is not right, I can achieve only 58-59 fps instead of vsynced 60 fps on 60 Hz display. The pipewire downgrade is the best for now

[psyke83]

Will be fixed in the next KWin 6.6 point release. As a temporary workaround you can rebuild KWin with the patch below instead of downgrading pipewire (probably a cleaner solution).

https://invent.kde.org/plasma/kwin/-/merge_requests/8939
https://invent.kde.org/plasma/kwin/-/merge_requests/8945

[solidv]

Will be fixed in the next KWin 6.6 point release. As a temporary workaround you can rebuild KWin with the patch below instead of downgrading pipewire (probably a cleaner solution).

https://invent.kde.org/plasma/kwin/-/merge_requests/8939 https://invent.kde.org/plasma/kwin/-/merge_requests/8945

what about gnome? just tested gnome 50 and still have the same issue

[psyke83]

Will be fixed in the next KWin 6.6 point release. As a temporary workaround you can rebuild KWin with the patch below instead of downgrading pipewire (probably a cleaner solution).
https://invent.kde.org/plasma/kwin/-/merge_requests/8939 https://invent.kde.org/plasma/kwin/-/merge_requests/8945

what about gnome? just tested gnome 50 and still have the same issue

I'm less certain that mutter will accept a PR because they deliberately changed the maxFramerate behaviour here.

Nevertheless, mutter's pacing works well when constrained to the host rate, so #4875 will be a satisfactory fix for mutter ( kwin will continue using variable rate), and can close this issue.

[solidv]

Will be fixed in the next KWin 6.6 point release. As a temporary workaround you can rebuild KWin with the patch below instead of downgrading pipewire (probably a cleaner solution).
https://invent.kde.org/plasma/kwin/-/merge_requests/8939 https://invent.kde.org/plasma/kwin/-/merge_requests/8945

what about gnome? just tested gnome 50 and still have the same issue

I'm less certain that mutter will accept a PR because they deliberately changed the maxFramerate behaviour here.

Nevertheless, mutter's pacing works well when constrained to the host rate, so #4875 will be a satisfactory fix for mutter ( kwin will continue using variable rate), and can close this issue.

Working fine for me. Thanks