migrate from kmsgrab

[ReenigneArcher]

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

kmsgrab is deprecated/unsupported

Expected Behavior

No response

Additional Context

• HDR Streaming Very Dark After Plasma 6.2 Update #3298 (comment)
• Can't stream a headless monitor created with Hyprland #2955 (comment)
• KMS + Headless + Nvidia: Unknown Monitor connector type [Meta] #2250 (comment)

Host Operating System

Linux

Operating System Version

Architecture

other, n/a

Sunshine commit or version

Package

other (not listed)

GPU Type

n/a

GPU Model

GPU Driver/Mesa Version

Capture Method

KMX (Linux)

Config

No response

Apps

No response

Relevant log output

*

[Zamundaaa]

FWIW one issue you'll come across with this is that the screencast portal doesn't support HDR streaming yet. I'd be happy to help out with fixing that on the KWin side though

[Quackdoc]

I believe there are two primary options for this

• Pipewire capture support + portals
• The new wayland protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124

the wayland protocol is an alternative to wlr-screencapture and has PRs for both cosmic and wlroots. https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4545 pop-os/cosmic-comp#365

I would love to see both supported. Pipewire + xdg portals gives a good basis, but on my custom streaming machines, I like to keep them as minimal as possible and to that point would like to avoid installing pipewire+portals all together.

[ReenigneArcher]

The first option has an open PR here: #2507

Not sure what's left before that's ready to merge, but right now there are merge conflicts.

[Quackdoc]

Loosing kmsgrab also means loosing the capability of doing things such as session swapping with sunshine. Though this may be possible to bridge using something like gstreamer + pipewire, this won't be compatible with portals (and obviously) wont be compatible with wayland capture protocols either.

I had realized recently that I do actually use this feature a small amount as depending on the task I may session swap to something such as gamescope or another x11 compositor. I think pipewire support would be able to adequately replace this, however im not sure if any tools for this currently exist that would adequately convert from kmsgrab to pipewire (gstreamer does not support kmscapture for instance)

AFAIK portals support also doesn't tend to lend itself well to unattended setups. As such I don't think portals is a suitable replacement for kmsgrab.

[JustPlainGarak]

I have seen in the past other applications programmatically grab a specified screen without the need to interact with the Pipewire portal to select a screen or application.

Now, this was for an Electron application so the implementation would obviously not be one to one. Also, hard coding a screen to capture was a temporary workaround to a bug in the Electron version being used at the time. However, I suspect (not being familiar with methods for calling Pipewire portals) that a similar solution could be implemented in Sunshine where you define the screen number in the Sunshine config and Sunshine grabs that screen id to pass to Pipewire.

Here's the commit from WebCord, the app I was talking about, that hard-coded the screen id being sent to Pipewire from the application. SpacingBat3/WebCord@f26e95b

[Zamundaaa]

AFAIK portals support also doesn't tend to lend itself well to unattended setups. As such I don't think portals is a suitable replacement for kmsgrab.

You may need to approve permissions for screen recording and remote input the very first time the app gets started, but it can restore those permissions later, without any input from the user.

I have seen in the past other applications programmatically grab a specified screen without the need to interact with the Pipewire portal to select a screen or application.

There is no way around the portal, and no need to try to work around it either. With the remote desktop portal, after getting that initial permission, sunshine gets free access to both record all screens and to emulate input devices without any hacks, and without the user having to jump through hoops to set any of it up.

[Quackdoc]

You may need to approve permissions for screen recording and remote input the very first time the app gets started, but it can restore those permissions later, without any input from the user.

Does KDE persist even across reboots? I know with gnome in the past even with persist_mode=2, the token can still expire after some time or after reboots. Though this may have changed, this has been a rather annoying issue for rustdesk users to contend with.

Another issue with the portals is consistency, this is all assuming the portal even supports persist, which is itself not a given thanks to the nature of wayland. That's not to say portals isn't a good choice, for most of the setups I maintain, I have no doubt it would be the goto, and it's the only decent choice for supporting flatpak. I just don't see it as a proper replacement to kmsgrab.

[Lunaphied]

One approach that maybe should be explored is supporting something like https://github.com/nowrep/obs-vkcapture directly for Sunshine, which should be independent of compositor behavior and provides a path towards capturing HDR output.

At least on KDE my experience is that portals are fine for say sharing something for a meeting but often there's issues like selecting a window capture when you needed to select a screen capture, applications launching to screens other than expected, screen capture not capturing certain games when doing screen capture and needing application capture or vis versa. It's too reliant on a lot of variables going right in an unattended environment even if token restoration was absolutely perfect (which it's not).

The way you work around portals is by directly implementing a compositor plugin for KWin (which is how the screenshot interface is implemented), but this is barely documented and incredibly unclear. It also seems like overkill to do an entire compositor specific plugin for an application that is trying to be generic