-
Couldn't load subscription status.
- Fork 55
Add support for org.freedesktop.ScreenSaver #164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
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. |
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". |
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.
|
Added |
|
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... |
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. |
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.
A collision check should be fine, shouldn't it? What side effects would this have?
Is it not worthwhile to merge this anyway? After all, perfect is the enemy of good. This still make QOL better for users.
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? |
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.
No, if an idle inhibitor is active, all clients using the 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. |
|
Disabling the portal inhibitor via |
|
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 = "*";
}; |
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
-sflag 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)