caffeine-ng
caffeine-ng copied to clipboard
WhyNotHugo
DpmsInhibitor is **not** applicable. May make the system crash on suspend
DpmsInhibitor not being applicable is a problem in both with v3.5.1 and the git version.
This is my output in v3.5.1:
/usr/lib/python3.9/site-packages/caffeine/main.py:61: PyGIWarning: AppIndicator3 was imported without specifying a version first. Use gi.require_version('AppIndicator3', '0.1') before import to ensure that the right version gets loaded.
from gi.repository import AppIndicator3
INFO:caffeine.core:Caffeine is starting up...
INFO:caffeine.core:Audio playback detected (spotify). Inhibiting.
INFO:caffeine.core:GnomeInhibitor is applicable, state: True
INFO:caffeine.core:XorgInhibitor is applicable, state: True
INFO:caffeine.core:XdgScreenSaverInhibitor is applicable, state: False
server does not have extension for +dpms option
INFO:caffeine.core:DpmsInhibitor is applicable, state: False
INFO:caffeine.core:
server does not have extension for +dpms option is spammed in the console and journalctl with the git version.
Additionally the last time the system suspended I could no longer access my pc neither in GUI nor in tty.
I am not sure if caffeine (git version) is related to it, but the following is its last output i have in journalctl a few minutes before the suspension of my pc, but after the system was blocked and the screen blacked out :
apr 01 13:30:38 thinkpad-t480 caffeine.desktop[39135]: server does not have extension for -dpms option
apr 01 13:30:48 thinkpad-t480 caffeine.desktop[39184]: server does not have extension for +dpms option
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: Traceback (most recent call last):
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/core.py", line 131, in run_all_triggers
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.apply_desired_status(show_notification)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/core.py", line 271, in apply_desired_status
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: inhibitor.set(inhibit_screen)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/inhibitors.py", line 46, in set
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.uninhibit()
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/inhibitors.py", line 83, in uninhibit
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.__proxy.Uninhibit(self.__cookie)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/dbus/proxies.py", line 141, in __call__
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: return self._connection.call_blocking(self._named_service,
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: reply_message = self.send_message_with_reply_and_block(
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: dbus.exceptions.DBusException: org.gnome.SessionManager.GeneralError: Unable to uninhibit: Invalid cookie
distro: Manjaro Linux DE: GNOME 40 on Wayland
EDIT: i tried to trigger suspension again with caffeine (git version) while playing music. While caffeine still couldn't prevent the pc from suspending and reported the same error i reported above, I could get the control of the system back both in gui and tty.
I am sorry. This must be related to the fact that i am on Wayland and caffeine doesn't officially support it.
I close the issue
#44 apparently managed to make it work on wayland, though. Could this me due to GNOME 40?
Probably using a similare command to the following could solve the issue for Wayland users, preventing the screen from dimming on GNOME.
gsettings set org.gnome.settings-daemon.plugins.power idle-dim false
We should see what's the command on KDE Wayland. I suspect this is the line causing the issue because it assume Xorg is running: https://github.com/caffeine-ng/caffeine-ng/blob/2972c04f57cbf59daf097e3535dc52d3bfb3e41f/caffeine/inhibitors.py#L181
I reopen the issue in hope to have a discussion.
I'm very confused by this:
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: Traceback (most recent call last):
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/core.py", line 131, in run_all_triggers
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.apply_desired_status(show_notification)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/core.py", line 271, in apply_desired_status
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: inhibitor.set(inhibit_screen)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/inhibitors.py", line 46, in set
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.uninhibit()
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/caffeine/inhibitors.py", line 83, in uninhibit
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: self.__proxy.Uninhibit(self.__cookie)
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/dbus/proxies.py", line 141, in __call__
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: return self._connection.call_blocking(self._named_service,
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: File "/usr/lib/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: reply_message = self.send_message_with_reply_and_block(
apr 01 13:30:58 thinkpad-t480 caffeine.desktop[30468]: dbus.exceptions.DBusException: org.gnome.SessionManager.GeneralError: Unable to uninhibit: Invalid cookie
I wonder if Gnome changed something on their API and those cookies now expire or something. caffeine stores the cookie that Gnome returns. :/
Probably using a similare command to the following could solve the issue for Wayland users, preventing the screen from dimming on GNOME.
gsettings set org.gnome.settings-daemon.plugins.power idle-dim false
Makes sense. Do you know how to determine if this is applicable or not?
I suspect this is the line causing the issue because it assume Xorg is running: https://github.com/caffeine-ng/caffeine-ng/blob/2972c04f57cbf59daf097e3535dc52d3bfb3e41f/caffeine/inhibitors.py#L181
Yes, that's causing the extra logging. Looks like applicable is not defined for DpmsInhibitor. I think it should call xset to determine if X is running and supports dpms.
Makes sense. Do you know how to determine if this is applicable or not?
I didn't like that solution very much tbh. Lately I tried to search for some kind of standards between all DEs & compositors. I found the following 2 options:
idle-inhibit, a Wayland unstable protocol. It's worth saying that pretty much every wayland protocol is "unstable".- A relatively new xdg portal
I wrote two simple tests. But please: bear in mind that I have never programmed with Gtk nor with dbus. These results could very much depend on that (especially the one that uses dbus).
I tired to run the tests on GNOME & KDE.
Wayland protocol
GTK supports the wayland protocol since this MR. My test appear to work on GNOME-Wayland. On GNOME-X11 and KDE it seems not to. I don't know who's fault is that: Kwin? My test? Gtk implementation being mutter-specific? Additionally i found the following MR for mutter. It's still open. And i cannot properly understand it.
Portals
The xdg-portal test, instead, doesn't seem to work on GNOME. With dbus_monitor I see the following activity:
dbus-monitor.log
method call time=1619301285.710432 sender=:1.94 -> destination=:1.149 serial=280 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.impl.portal.Inhibit; member=Inhibit
object path "/org/freedesktop/portal/desktop/request/1_167/t"
string ""
string "org.gtk.TestApp"
uint32 15
array [
dict entry(
string "reason"
variant string "Testing xdg-portal inhibition!"
)
]
method call time=1619301285.711080 sender=:1.149 -> destination=:1.13 serial=140 path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; member=Inhibit
string ""
uint32 0
string "Testing xdg-portal inhibition!"
uint32 15
method return time=1619301285.711151 sender=:1.149 -> destination=:1.94 serial=141 reply_serial=280
error time=1619301285.711594 sender=:1.13 -> destination=:1.149 error_name=org.gnome.SessionManager.GeneralError reply_serial=140
string "Application ID not specified"
signal time=1619301285.711639 sender=:1.94 -> destination=:1.167 serial=281 path=/org/freedesktop/portal/desktop/request/1_167/t; interface=org.freedesktop.portal.Request; member=Response
uint32 0
array [
]
method call time=1619301286.241677 sender=:1.167 -> destination=:1.94 serial=7 path=/org/freedesktop/portal/desktop/request/1_167/t; interface=org.freedesktop.portal.Request; member=Close
method call time=1619301286.242749 sender=:1.94 -> destination=:1.149 serial=282 path=/org/freedesktop/portal/desktop/request/1_167/t; interface=org.freedesktop.impl.portal.Request; member=Close
method return time=1619301286.243680 sender=:1.149 -> destination=:1.94 serial=142 reply_serial=282
method return time=1619301286.244565 sender=:1.94 -> destination=:1.167 serial=283 reply_serial=7
Even with /lib/xdg-desktop-portal-gtk --replace --verbose I get a Application ID not specified error, although i think i did.
On KDE it seems to work on both X11 and Wayland!
xdp-kde-inhibit: Inhibit called with parameters:
xdp-kde-inhibit: handle: "/org/freedesktop/portal/desktop/request/1_97/t"
xdp-kde-inhibit: app_id: ""
xdp-kde-inhibit: window: "org.gtk.Example"
xdp-kde-inhibit: flags: 15
xdp-kde-inhibit: options: QMap(("reason", QVariant(QString, "Testing xdg-portal inhibition!")))
xdp-kde-request: "org.freedesktop.impl.portal.Request"
xdp-kde-request: "Close"
xdp-kde-request: "/org/freedesktop/portal/desktop/request/1_97/t"
Unfortunately, tho, as soon as I click the button to toggle-off the inhibition in kde, the app crashes. I don't know why :/
Sure is that it manages to disable the inhibition before crashing!
Conclusions
Finally I think that we should try to go for the portal implementation as that seems like the most long-lasting protocol and it appears to be designed directly for applications. I can see it establishing between all DEs in the near future. Plus it's a start to properly package caffeine-ng with flatpak! In order to do that I would need your help. As I said earlier I've no experience with Gtk/dbus and, before filing an issue upstream I would like to have a double checkfrom you on the tests I wrote and a brief discussion on the approach. Could you please help me with that? ^^
I suspect this is the line causing the issue because it assume Xorg is running: https://github.com/caffeine-ng/caffeine-ng/blob/2972c04f57cbf59daf097e3535dc52d3bfb3e41f/caffeine/inhibitors.py#L181
Yes, that's causing the extra logging. Looks like
applicableis not defined forDpmsInhibitor. I think it should callxsetto determine if X is running and supports dpms.
Oh yeah, that makes sense!
Fyi this is a good read: https://arnaudr.io/2020/09/25/inhibit-suspending-the-computer-with-gtkapplication/
He suggests using gtk_application_inhibit(), tho. Seems like it should work everywhere apart from XFCE because they're using a deprecated API. It would be extremely good if we could use only that interface as it would simplify enormously inhibitors.py.
In all fairness, tho, i think i tried to use gtk_application_inhibit() through the python API in my first test, but it didn't work on my KDE desktop and GNOME-X11. It could all be due to the version of Gtk API i used tho. I don't really know
Good news! After almost a year my work in order to use portals (which I think it's drawing to become the new standard cross-DEs, also thanks to wayland) in order to inhibit suspension for un-sendboxed application is completed!
- KDE fixed a bug where their frontend implementation didn't work properly [bug 436453]
- and today the portal backend accepted, improved & merged my request for allowing to make certain portal calls (including
Inhibit()) complete for un-sendboxed applications. This means that my demo works with GNOME as well—which is a bit picky about who's allowed to inhibit the session [bug 579]
What do you think about going forward with this idea, @WhyNotHugo? I could also see this as an option for having less inhibitors, since Portals are becoming really widespread across all the linux desktop
Original issue is now fixed on master via f2c0bacf1b65645198df7980320cf4d0ab858917
Regarding direction: I'm thinking of addressing the Wayland support so I can use caffeine on swaywm. I've mentioned in the past that I haven't been really using caffeine, and Wayland support would put caffeine back in the "things I use" list.
Portal support would be very welcome too. A few inhibitors use dbus, they are a useful reference, e.g.:
https://github.com/caffeine-ng/caffeine-ng/blob/b7deb6e98623a0d6ee8218fae6b9c2f930caefb7/caffeine/inhibitors.py#L146-L161
d-feet is also very handy when experimenting simple d-bus method calls.
This project has moved to codeberg.
Follow-up for this issue is at https://codeberg.org/WhyNotHugo/caffeine-ng/issues/62