Skip to content

Conversation

@ambadoom
Copy link

I've patched in support for the org.freedesktop.ScreenSaver interface for my own use.

Not sure if yet another way of inhibiting idle is in-scope here but thought I'd create a PR just in case.

The feature is locked behind a -s flag as it requires claiming ownership of the D-Bus name.

Currently this requires building with systemd or elogind support, although in theory all it needs is access to D-Bus.

I haven't tested this building with elogind but don't think there is any reason to expect it to work differently to systemd here.

(As a side note, I also have a patch that detects if stderr is the systemd journal and if so omits timestamps and emits log-level markers. Let me know if there is any interest)

@Ciubix8513
Copy link

This doesn't seem to work with vlc, tho it does work with playing videos on youtube (using firefox). And it doesn't look to be a vlc issue, code on their side looks correct.

@ambadoom
Copy link
Author

This doesn't seem to work with vlc

Looks like vlc is trying to call Inhibit on "/ScreenSaver" rather than "/org/freedesktop/ScreenSaver". I had previously assumed binding to the latter would be enough.

From a quick search I can't find documented anywhere what paths we should be using but gnome seems to use those two paths[0] so that seems like a good bet.

I'll come up with a patch to add "/ScreenSaver".

[0] : https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/screensaver-proxy/gsd-screensaver-proxy-manager.c

Some programs such as vlc look to /ScreenSaver rather than
/org/freedesktop/ScreenSaver for their inhibiting. This brings us in
line with what gnome does.
@ambadoom
Copy link
Author

Added /ScreenSaver. I've tested it working with vlc.

@yuannan
Copy link

yuannan commented May 4, 2025

Is there anything I can do to help this get merged? I've had to manually disable the idle in swaybar for a while now...

@kennylevinsen
Copy link
Member

  1. I don't understand the use-case, as the Wayland idle inhibition protocol is widely supported and used by KDE as well. That protocol also specifically inhibits idle for a particular window so that a video playing only inhibits while visible.
  2. It is perfectly valid to run multiple instances of swayidle, while I believe this change would clash on the screensaver dbus name?
  3. This change would not inhibit any idle timers in other clients (swayidle or not) using the idle protocol.

While this is a portal interface, it also cannot currently be implemented in xdg-desktop-portal-wlr as we have no means of blanket inhibition over Wayland protocols, which I believe the dbus protocol requires? One would either need such a protocol or a sway command doing the same to be able to implement this.

@yuannan
Copy link

yuannan commented May 4, 2025

  1. I don't understand the use-case, as the Wayland idle inhibition protocol is widely supported and used by KDE as well. That protocol also specifically inhibits idle for a particular window so that a video playing only inhibits while visible.

Firefox is calling this, and FireFox is quite commonly used. Do you not think it'll be worth putting it in? If not, what do you personally use? I don't mind if this PR is not merged, but I'd like to avoid having to manually inhibit it while watching videos.

2. It is perfectly valid to run multiple instances of swayidle, while I believe this change would clash on the screensaver dbus name?

A collision check should be fine, shouldn't it? What side effects would this have?

3. This change would not inhibit any idle timers in other clients (swayidle or not) using the idle protocol.

Is it not worthwhile to merge this anyway? After all, perfect is the enemy of good. This still make QOL better for users.

While this is a portal interface, it also cannot currently be implemented in xdg-desktop-portal-wlr as we have no means of blanket inhibition over Wayland protocols, which I believe the dbus protocol requires? One would either need such a protocol or a sway command doing the same to be able to implement this.

If you have a spec that you make you happy to merge this I'd be happy to do it. imo, I think this is worth merging despite it's issues. Or do you think this will be better implemented in another project?

@kennylevinsen
Copy link
Member

kennylevinsen commented May 4, 2025

Firefox is calling this, and FireFox is quite commonly used. Do you not think it'll be worth putting it in?

Firefox should already work as it uses the Wayland idle protocol. It switches through the list of inhibitors on failure, so it won't reach the Wayland protocol if you're running something implementing one of the dbus interfaces it tests first. Make sure that's not the case.

If there are idle inhibition issues with Firefox (when not running conflicting services like ScreenSaver or Inhibit portals), that's a bug in Firefox (or in sway if the inhibitor is active but not correctly enforced). Sway debug logging includes some info about when idle inhibitors are created and destroyed.

A collision check should be fine, shouldn't it?

No, if an idle inhibitor is active, all clients using the ext-idle-notify protocol (all swayidle instances for example) should be equally inhibited.

There isn't a "main" instance of swayidle that could own this interface, so if they can't all listen, none will have to listen. It's also not uncommon to have e.g. bar widgets and such for manual idle inhibition that work by killing swayidle when inhibiting and running it again when idle should resume. In this case, all the ScreenSaver inhibitors would be lost, and clients like Firefox would move on to other protocols and never try ScreenSaver again.

@Consolatis
Copy link

Disabling the portal inhibitor via org.freedesktop.impl.portal.Inhibit=none (apparently announced via GTK portal implementation even though it has actually no chance to set it in other compositors than gnome) seems to work around the firefox "first-comes-first-and-only-served" issue. See for example labwc/labwc#1503 for a discussion about this.

@yuannan
Copy link

yuannan commented May 4, 2025

Special thanks to @kennylevinsen, turns out I had my NixOS home manager misconfigured.

Here is the diff if anyone is interested:

         xdg = {
             portal = {
                 enable = true;
+
+                configPackages = [
+                    pkgs.xdg-desktop-portal-wlr
+                ];
                 extraPortals = [
                     pkgs.xdg-desktop-portal-wlr
-                    pkgs.xdg-desktop-portal-gtk
-                    pkgs.kdePackages.xdg-desktop-portal-kde
                 ];
-                config.common.default = "*";
             };

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants