Skip to content

fix(linux/pipewire): try variable rate for non-KWin compositors - #5569

Open
psyke83 wants to merge 2 commits into
LizardByte:masterfrom
psyke83:pw_mutter_variable_rate
Open

fix(linux/pipewire): try variable rate for non-KWin compositors#5569
psyke83 wants to merge 2 commits into
LizardByte:masterfrom
psyke83:pw_mutter_variable_rate

Conversation

@psyke83

@psyke83 psyke83 commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Description

Variable rate capture works better on mutter, but since GNOME 50
we encountered negotiation failures.

It seems that if we negotiate maxFramerate with a default of variable rate
but relaxed maximum value, the final negotiation phase actually lands on
variable rate (after being constrained to the host refresh rate); mutter
debug included:

[2026-08-29 00:38:43.671]: Info: [pipewire] Framerate (from compositor): 0/1
[2026-08-29 00:38:43.671]: Info: [pipewire] Framerate (from compositor, max): 60/1
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 60/1))
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 0/1))
[2026-08-29 00:38:43.672]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)

Pacing does seem to be improved and Sunshine reports variable rate for the
final negotiation phase.

Upstream MR has been submitted, but doesn't seem strictly necessary:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5278

With upstream MR applied, output is more uniform:

[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 0/1))

Screenshot

Issues Fixed or Closed

Fixes #5000

Roadmap Issues

Type of Change

  • feat: New feature (non-breaking change which adds functionality)
  • fix: Bug fix (non-breaking change which fixes an issue)
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
  • refactor: Code change that neither fixes a bug nor adds a feature
  • perf: Code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies
  • ci: Changes to CI configuration files and scripts
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit
  • BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

  • Code follows the style guidelines of this project
  • Code has been self-reviewed
  • Code has been commented, particularly in hard-to-understand areas
  • Code docstring/documentation-blocks for new or existing methods/components have been added or updated
  • Unit tests have been added or updated for any new or modified functionality

AI Usage

See our AI usage policy.

  • None: No AI tools were used in creating this PR
  • Light: AI provided minor assistance (formatting, simple suggestions)
  • Moderate: AI helped with code generation or debugging specific parts
  • Heavy: AI generated most or all of the code changes

@psyke83
psyke83 force-pushed the pw_mutter_variable_rate branch 3 times, most recently from c958f80 to b18310f Compare August 29, 2026 03:03
Variable rate capture works better on mutter, but since GNOME 50
we encountered negotiation failures.

It seems that if we negotiate maxFramerate with a default of variable rate
but relaxed maximum value, the final negotiation phase actually lands on
variable rate (after being constrained to the host refresh rate); mutter
debug included:

[2026-08-29 00:38:43.671]: Info: [pipewire] Framerate (from compositor): 0/1
[2026-08-29 00:38:43.671]: Info: [pipewire] Framerate (from compositor, max): 60/1
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 60/1))
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 0/1))
[2026-08-29 00:38:43.672]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)

Pacing does seem to be improved and Sunshine reports variable rate for the
*final* negotiation phase.

Upstream MR has been submitted, but doesn't seem strictly necessary:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5278

With upstream MR applied, output is more uniform:

[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
[2026-08-29 00:35:42.248]: Info: [pipewire] Framerate (from compositor): 0/1 (variable rate capture)
SCREEN_CAST: Video format changed to 1920x1080 (framerate: 0/1 (max: 0/1))
@psyke83
psyke83 force-pushed the pw_mutter_variable_rate branch from b18310f to bbfcf5f Compare August 29, 2026 03:08
@psyke83
psyke83 marked this pull request as ready for review August 29, 2026 04:11
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Gnome with 60hz display causes framerate issues

1 participant