Inhibitsuspend: systemd-inhibit, elogind-inhibit, and logind dbus support#1016
Inhibitsuspend: systemd-inhibit, elogind-inhibit, and logind dbus support#1016ryneeverett wants to merge 2 commits into
Conversation
89a9534 to
5eebdf0
Compare
- I did not test on an elogind system. - This leaves a zombie process which seems to be cleaned up on the next invocation of systemd-inhibit. This doesn't seem to be a problem. - I intentionally gave these higher precedence than sway because sway's idle inhibition has been broken lately: swaywm/sway#8959
Note that whereas the DbusSuspendAdapter uses interfaces on the SessionBus, logind is on the SystemBus.
5eebdf0 to
8c0395e
Compare
|
There is also the xdg desktop portal inhibit suspend method, which should in theory, be DE-agnostic (ish): |
|
Nice. I don't have that portal on my sway systems though so I'm not inclined to implement without testing. (I didn't really set out to support everything in the world here. I started with the lazy systemd-inhibit solution suggested by the TODO comment and then pursued the more elegant dbus solution.) |
|
I did some testing on my Guix system, which is "interesting" because it does not use systemd, it does have elogind, and I run Gnome on it. (This is basically a default Guix desktop installation.) On 4.2.1, the plugin crashes every time I play music. I didn't dig into it but I presume that the Gnome adapter is what is crashing and is doing so because the dbus interface doesn't actually exist. Running with this PR, the plugin does not crash -- surprisingly with the Logind adapter -- and the inhibitor shows up in |
I don't know if there are actually any systems which support systemd-inhibit but not the logind bus. I also don't understand the ecosystem enough to know why all these desktop environments have their own dbus interfaces to handle suspend inhibitors and wonder if the logind bus would also work for them. I'm happy to rework or break this into separate PR's if somebody knows better.