Linux Flatpak Player Doesn't Inhibit Power Management

Plex Players Desktop Players
1

Player Version#: 1.51.1

While playing movies and shows, the Plex desktop app doesn’t inhibit power management, resulting in the screen locking during playback.

2

We’ve added more inhibit methods which should be present in the next version. Unfortunately the documentation on some of these is very lacking (one of which is only documented to exist in the flatpak documentation without explicitly indicating when it is supposed to be used). So hopefully this catches more of user’s cases.

3

I’m not sure if this should be out by now? If so, it’s still not working.

This used to be a freedesktop spec
https://www.freedesktop.org/wiki/Specifications/power-management-spec/

It looks like KDE respects org.freedesktop.PowerManagement and org.freedesktop.PowerManagement.Inhibit (which I believe to be part of the old spec):

It also looks like KDE supports (what I suspect to be the newer and detailed spec from logind – part of systemd):

https://freedesktop.org/wiki/Software/systemd/logind/

4

It’s already inhibiting org.freedesktop.PowerManagement. I don’t know what is necessary to work in your configuration. It seems that every distro/window manager/etc has a different method of inhibiting and fail to document much of it. Additionally there’s no way to know what happens through the snap dbus proxy layer.

5

EDIT 2: Just noting as a preface, this post is largely wrong, my subsequent reply is “more correct.”

Aha! You actually gave me the answer. This isn’t a problem with the software, it’s a problem with the packaging. The flatpak (not snap) when examined with flatseal doesn’t expose org.freedesktop.PowerManagement on the system bus.

This is very similar to what this user is proposing: Add access to org.freedesktop.ScreenSaver on system D-Bus by scribblemaniac · Pull Request #6 · flathub/tv.plex.PlexDesktop · GitHub

Except org.freedesktop.PowerManagement needs exposed rather than org.freedesktop.ScreenSaver (which KDE doesn’t seem to pay attention to; but it doesn’t really hurt to expose).

This needs to be done for any dbus integrations you guys have, or you need to just request access to the system-bus via --socket=system-bus (but it’s better practice to explicitly list what you’re using).

What is striking me as odd is that inspecting the dbus state, qdbus-qt5 --system org.freedesktop.PowerManagement fails while qdbus-qt5 org.freedesktop.PowerManagement succeeds – which is the opposite of what seems to be true with the flatpak options (yikes).

I’m not sure what’s going on there, and I’m going to reach out to the KDE guys to see if they know what’s going on/see if there’s something that’s preventing KDE from using whatever GNOME is using these days (assuming it’s not the org.freedesktop.PowerManagement spec).

(Also as linked above, logind will not help you with this; there’s footnote that states it’s only for things like sleep/hibernate/suspend/auto power off. My apologies, not helpful after all)

If someone finds this before it’s fixed in the flatpak, it can be worked around by using the flatseal application to change the default switches and be more permissive or via launching with the flag --system-talk-name=org.freedesktop.PowerManagement (EDIT: See below, this should be --system-talk-name=org.freedesktop.ScreenSaver).

6

Looking into this more, it seems the “proper spec” should be org.freedesktop.ScreenSaver as implemented in kscreenlocker (kscreenlocker/interface.cpp at 9b4205e19c3f6ea5358c39dc886139c0c8250462 · KDE/kscreenlocker · GitHub).

The fact that PowerManagement works for this seems to be a bug. (EDIT 3: See 421011 – /org/freedesktop/PowerManagement/Inhibit shouldn't prevent locking screen)

Writing a simple test program, KDE’s implementation does seem to be responding to the org.freedesktop.ScreenSaver spec correctly.

import dbus

bus = dbus.SessionBus()
dbus_obj = bus.get_object('org.freedesktop.ScreenSaver', '/org/freedesktop/ScreenSaver')
object.Inhibit('foo', 'bar')

This leads to a successful inhibit that “foo is currently blocking sleep and screen locking (bar)”. This is on the session bus.

Attempting to expose this via flatpak run --talk-name=org.freedesktop.ScreenSaver tv.plex.PlexDesktop doesn’t have any affect, this leads me to believe Plex is doing something odd here.

If you reference the flatpak documentation as well, it’s noted that the session bus should be exposed by default anyways: Flatpak Command Reference — Flatpak documentation

Thus, this should be as “simple” as the above script with no special settings/flags required (though perhaps something else has caused Plex to move towards this current implementation)?

EDIT: Adding --system-talk-name=org.freedesktop.ScreenSaver seems to work as well. So it would appear the afforementioned PR to the flatpak should be merged (ref: Add access to org.freedesktop.ScreenSaver on system D-Bus by scribblemaniac · Pull Request #6 · flathub/tv.plex.PlexDesktop · GitHub). Though I’d suggest looking into why this needs exposed via the system bus instead of the session bus.

EDIT 2: If you believe there’s an issue with flatpak itself, and Plex is correctly trying to communicate on the session bus. I’d open an issue with flatpak here: GitHub - flatpak/flatpak: Linux application sandboxing and distribution framework

Notably using dbus.SystemBus() as a diagnostic step in the above Python code, does lead to a crash/does not function. I believe Plex may be doing the right thing here, however Flatpak for some reason is not.

7

FWIW, the apps have inhibited this one from the beginning as the original code was taken from PMP which did the same. Currently it tries to do 3 different inhibit methods.

It does try to use the system bus instead of the session bus (again like the PMP code). I’m not sure if this is required or rather because the power methods may require the system bus. Perhaps this is the issue.

8

As noted in the Python code about, it should be working with just the SessionBus, it’s actually quite strange that it’s working at all if it’s trying to use the SystemBus. It might warrant some investigation to see if there’s a “gnarly” workaround to make that happen that’s complicated things.

FWIW; I appreciate your involvement on this thread and responsiveness. I apologize that this has been so convoluted and complicated to get right.

9

Actually looking at your code here:

  if (QDBusConnection::systemBus().isConnected())
  {
    QDBusInterface iface(DBUS_SCREENSAVER_SERVICE_NAME, DBUS_SCREENSAVER_SERVICE_PATH,
                         DBUS_SCREENSAVER_INTERFACE, QDBusConnection::sessionBus());

It looks like it uses the sessionBus but for some reason checks to see if the systemBus is availible before trying to do that. So the code starts working when the system bus is exposed, despite operating on the sessionBus. I suspect this is your problem.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.