XDG Portal requires service change

[psyke83]

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

The XDG Portal is not correctly identifying Sunshine as the current streaming application via native packages. The main reason is that the service cannot identify Sunshine via the systemd service name (see context link).

In order to resolve this, we need to take several steps.

• Normalize all packaging to use the FQDN naming convention everywhere (e.g. for icons), not just for the Flatpak package.
• Rename the Sunshine service. At a minimum, we should consider renaming the unprivileged unit to app-sunshine to enable Portal recognition, but the real name should technically follow the FQDN pattern: app-dev.lizardbyte.app.Sunshine. Perhaps we can also install a service alias that's simply named sunshine for legacy support? Or alternatively, we can rename the privileged unit back to sunshine and just use the new name for the unprivileged unit.

@ReenigneArcher I'm willing to implement the changes but I'd need feedback on the direction you'd like to go with this.

Expected Behavior

XDG Portal should recognize Sunshine correctly. In KDE, you should see "Sunshine" appear as the streaming application in the XDG notification icon, and the generic red icon should possibly use Sunshine's real icon too (but I'm not sure how to fix the latter yet).

Additional Context

https://systemd.io/DESKTOP_ENVIRONMENTS/

Host Operating System

Linux

Operating System Version

Fedora 43

Architecture

amd64/x86_64

Package

n/a

GPU Type

AMD

GPU Model

RX 6600

GPU Driver/Mesa Version

25.3.5

Capture Method

XDG Portal Grab (Linux)

Apps

Log output

Online logs

No response

[ReenigneArcher]

Normalize all packaging to use the FQDN naming convention everywhere (e.g. for icons), not just for the Flatpak package.

I'm good with this. I previously normalized some things using the FQDN in #3954 but I guess I missed the icons.

Rename the Sunshine service. At a minimum, we should consider renaming the unprivileged unit to app-sunshine to enable Portal recognition, but the real name should technically follow the FQDN pattern: app-dev.lizardbyte.app.Sunshine. Perhaps we can also install a service alias that's simply named sunshine for legacy support? Or alternatively, we can rename the privileged unit back to sunshine and just use the new name for the unprivileged unit.

Let's follow the FQDN pattern. In my mind it's better to follow that and best practices and avoid clashes with any other programs that might be named "sunshine". I'd prefer not have an alias, but it's not a strong preference.

Thanks for all your effort trying making the XDG portal capture viable!

[psyke83]

Normalize all packaging to use the FQDN naming convention everywhere (e.g. for icons), not just for the Flatpak package.

I'm good with this. I previously normalized some things using the FQDN in #3954 but I guess I missed the icons.

Rename the Sunshine service. At a minimum, we should consider renaming the unprivileged unit to app-sunshine to enable Portal recognition, but the real name should technically follow the FQDN pattern: app-dev.lizardbyte.app.Sunshine. Perhaps we can also install a service alias that's simply named sunshine for legacy support? Or alternatively, we can rename the privileged unit back to sunshine and just use the new name for the unprivileged unit.

Let's follow the FQDN pattern. In my mind it's better to follow that and best practices and avoid clashes with any other programs that might be named "sunshine". I'd prefer not have an alias, but it's not a strong preference.

Thanks for all your effort trying making the XDG portal capture viable!

Do you have a preference regarding the privileged unit? It can't use the FQDN due to it already not being XDG compatible, but we could also use the opportunity to rename it back to sunshine (as long as it doesn't interfere with Portal recognition; I'll have to test to be sure).

Also, we might want to consider changing the KMS service (whatever it's called) to be the one that's enabled by default. Portal capture is currently excellent for me in terms of pacing and latency; with the active PR, it's better than KMS, but it's still rough around the edges. It could have multi-GPU issues, absolute pointer mode doesn't work, and I've seen instances where the portal token randomly gets forgotten and has to be re-confirmed via UI. Finally, I've not been testing extensively on GNOME, but I have seen GNOME hanging with a black screen after trying to reconnect from idle state on Ubuntu 24.04 and restarting the service didn't seem to resolve the issue.

[ReenigneArcher]

Do you have a preference regarding the privileged unit? It can't use the FQDN due to it already not being XDG compatible, but we could also use the opportunity to rename it back to sunshine (as long as it doesn't interfere with Portal recognition; I'll have to test to be sure).

It can go back to sunshine if you think that's best. This would work for all capture methods except XDG correct?

[psyke83]

Do you have a preference regarding the privileged unit? It can't use the FQDN due to it already not being XDG compatible, but we could also use the opportunity to rename it back to sunshine (as long as it doesn't interfere with Portal recognition; I'll have to test to be sure).

It can go back to sunshine if you think that's best. This would work for all capture methods except XDG correct?

I'm honestly not familiar with the capture methods besides kmsgrab and x11. I suspect that the x11 and wlr capture backends would work with the unprivileged unit, but I'm not sure that X11 capture should be used by anyone these days; it performed poorly when I last tried it. KMS capture also works on X11 for users that don't want to use Wayland, and it performs pretty decently.