You want something like:

https://gist.githubusercontent.com/fxthomas/9bdfadd972eaf7100b374042faac28c2/raw/94590f2ff10cfb59492c0995fba9a44ec9179691/gnome-inhibit.py

but with the service names and paths replaced

It's less work than whatever you were doing before.

Maybe I should add a kde-inhibit to kde-cli-tools
We have a similar request for nightmode

(In reply to David Edmundson from comment #1)
> You want something like:
> 
> https://gist.githubusercontent.com/fxthomas/9bdfadd972eaf7100b374042faac28c2/
> raw/94590f2ff10cfb59492c0995fba9a44ec9179691/gnome-inhibit.py
> 
> but with the service names and paths replaced
> 
> It's less work than whatever you were doing before.
> 
> Maybe I should add a kde-inhibit to kde-cli-tools
> We have a similar request for nightmode

Thanks for the reply. I do not think that is less work than what I was doing before. I used to just prepend a single line to any script to make it prevent sleep. Now, I need write my scripts, then write another script that calls 'inhibit.py myscript.sh'. Or, create an alias, but then myscript would not work portably if the alias does not exist in another machines env.
Also, suddenly all my scripts depend on python? That's not good.

I'm not sure I understand the reason for this change of behavior. If some programs exited without releasing their inhibition, surely that is a bug in that program not in powerdevil?

Similarly, this is now marked as not a bug, but isn't the command 'qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/PowerManagement/Inhibit Inhibit string:"Inhibit" string:"User requested"' correct? And isn't it supposed to prevent sleep? I feel like the fix for 423131 is a bug.

> If some programs exited without releasing their inhibition, surely that is a bug in that program not in powerdevil?

Programs do crash sometimes, you know. It was actually a bug in PowerDevil not releasing those inhibitions properly when the program quit before the inhibition came into effe

>Now, I need write my scripts, then write another script that calls 'inhibit.py myscript.sh'. 

That's maybe avoidable. Something like:

#!/bin/sh
trap 'kill $(jobs -p)' EXIT
inhibit.py read &
rest of my awesome scripts

#the read just to make it hang around, or we could also just change that script to idle after making the call
I can consider that use-case if there is support for a kde-inhibit binary.

> Programs do crash sometimes, you know. 

Yes I do know, but my point stands, a crash in a program is not a bug in powerdevil. Obviously I do see some benefit in powerdevil dealing with this situation, but it is causing me much more trouble than it's solving. 

> It was actually a bug in PowerDevil
> not releasing those inhibitions properly when the program quit before the
> inhibition came into effe

Right, so it shouldn't inhibit if the inhibition was not yet accepted (the first five seconds after requesting?). I see the same thing in the description at d21102cc6c7a4db204a29f376ce5eb316ef57a6e ('remove from pending'). Now, this has obviously been breaking my workflow a bit, but apparently the behavior before was not correct. But now, even when I write a little program like this:

#include <QDBusConnection>
#include <QDBusMessage>
#include <QThread>
#include <QDebug>

class SuspendInhibitor
{
 private:
  bool d_inhibited;
  uint d_cookie;
 public:
  inline SuspendInhibitor() : d_inhibited(false), d_cookie(-1)
  {}

  void inhibitSuspend()
  {
    if (d_inhibited)
      return;
    QDBusMessage inhibitCall = QDBusMessage::createMethodCall(QStringLiteral("org.freedesktop.PowerManagement.Inhibit"),
                                                              QStringLiteral("/org/freedesktop/PowerManagement/Inhibit"),
                                                              QStringLiteral("org.freedesktop.PowerManagement.Inhibit"),
                                                              QStringLiteral("Inhibit"));
    inhibitCall.setArguments({"Application", "Playing Music"});
    QDBusMessage reply = QDBusConnection::sessionBus().call(inhibitCall, QDBus::Block, 5000);
    if (reply.type() == QDBusMessage::ReplyMessage)
    {
      d_cookie = reply.arguments()[0];
      d_inhibited = true;
    }
  }

  void uninhibitSuspend()
  {
    if (!d_inhibited)
      return;

    QDBusMessage uninhibitcall = QDBusMessage::createMethodCall(QStringLiteral("org.freedesktop.PowerManagement.Inhibit"),
                                                                QStringLiteral("/org/freedesktop/PowerManagement/Inhibit"),
                                                                QStringLiteral("org.freedesktop.PowerManagement.Inhibit"),
                                                                QStringLiteral("UnInhibit"));
    uninhibitcall.setArguments({d_cookie});
    QDBusMessage reply = QDBusConnection::sessionBus().call(uninhibitcall, QDBus::Block, 5000);
    if (reply.type() == QDBusMessage::ReplyMessage)
      d_inhibited = false;
  }
};

int main()
{
  SuspendInhibitor spnd;
  spnd.inhibitSuspend();

  // Wait for the inhibition to go into effect!!!
  for (uint i = 0; i < 10; ++i)
  {
    qInfo() << "Sleeping " << i + 1;
    QThread::msleep(1000);
  }

  //spnd.uninhibitSuspend();

  qInfo() << "Exiting";

  return 0;
}

And watch org.freedesktop.PowerManagement.Inhibit.HasInhibit, I see somewhere during the 10 sec sleep that I get 'true' as a reply, but then when the program exits, the inhibition is lifted. At this point the inhibit was not pending, it had gone into effect, but it is still removed automatically.

>At this point the inhibit was not pending, it had gone into effect, but it is still removed automatically.

Yes. That sounds right.


My understanding is:

Inhibition should go away on process exit
That was the state in 2010-2015

In 2015 a delay was introduced to workaround chrome posting tiny inhibitions for sound notifications
eca79138c15575f6f523a8680919b407f84da2e2  

This introduced a bug where if you send a request then exit the inhibition stays.

People then started exploiting that bug understandably thinking it was deliberate behaviour (not helped that the specification docs are seemingly also offline)

That bug introduced in 2015 has since been fixed recently.

(In reply to David Edmundson from comment #6)
> >At this point the inhibit was not pending, it had gone into effect, but it is still removed automatically.
> 
> Yes. That sounds right.
> 
> 
> My understanding is:
> 
> Inhibition should go away on process exit
> That was the state in 2010-2015
> 
> In 2015 a delay was introduced to workaround chrome posting tiny inhibitions
> for sound notifications
> eca79138c15575f6f523a8680919b407f84da2e2  
> 
> This introduced a bug where if you send a request then exit the inhibition
> stays.
> 
> People then started exploiting that bug understandably thinking it was
> deliberate behaviour (not helped that the specification docs are seemingly
> also offline)

OK, well that's me I guess :( haha

> 
> That bug introduced in 2015 has since been fixed recently.

OK, I guess I'll have to figure something out. Thanks for your replies.

FYI: https://invent.kde.org/plasma/kde-cli-tools/-/merge_requests/2

Git commit 1f903bb93ce4fdc0f80268dcc23404ace542f70b by David Edmundson.
Committed on 14/08/2020 at 15:04.
Pushed by davidedmundson into branch 'master'.

Add utility to inhibit various actions

People want to use inhibitions with scripts, which is perfectly
sensible.

Most our inhibitors exit when the calling process quits, which is
something we definitely want, but it fails when we have people making
calls with qdbus/dbus-send and wondering why their inhibitions don't
work.

This tiny script puts surfaces all inhibitors in a way that's relatively
easy to use from shell scripts.
Related: bug 422436

M  +1    -0    CMakeLists.txt
A  +3    -0    kdeinhibit/CMakeLists.txt
A  +95   -0    kdeinhibit/main.cpp     [License: GPL (v2)]

https://invent.kde.org/plasma/kde-cli-tools/commit/1f903bb93ce4fdc0f80268dcc23404ace542f70b