ScreenSaver Specification

Since version 4.0, Clight implements and offers org.freedesktop.ScreenSaver API in place of supporting org.freedesktop.PowerManagement.Inhibited signal.

ScreenSaver spec is better in virtually any way, as it is really meant to pause screen dimming and dpms/screensaver kicking in. Thus, for example:

• Inhibition is only held for videos
• Chromium will only keep is inhibition ON while you're in a tab that is playing video. If you change tab, ScreenSaver inhibition will be dropped.

Instead, PowerManagement API is meant to inhibit powersave functions like suspend to ram/disk.
Consequently it is used by eg: chrome while listening to music, your torrent application to inhibit suspend while downloading, etc etc.

Sadly, ScreenSaver spec does not have an Inhibited signal, thus Clight cannot know whether an inhibition has been requested to eg: your DE power manager.
Consequently Clight has to provide the API implementation itself.
It works like this:

1. A program (Clight) creates a well known bus interface (org.freedesktop.ScreenSaver)
2. Other programs call org.freedesktop.ScreenSaver.Inhibit/UnInhibit when needed
3. Clight receives the request and paused its dimmer/dpms tools

But you cannot have multiple programs offering same bus name in dbus; therefore first program that will request org.freedesktop.ScreenSaver bus name will take its ownership.
This means that in major DEs ScreenSaver API will probably be provided by their power manager, instead of Clight.
In this case Clight starts monitoring dbus for org.freedesktop.ScreenSaver requests (same as busctl --user monitor org.freedesktop.ScreenSaver), and acts accordingly, as if these requests were made directly to it.

Finally, note that Clight implements { Inhibit, UnInhibit, GetActive, SimulateUserActivity } methods.