search

FedeDP / Clight

A C daemon that turns your webcam into a light sensor. It will adjust screen backlight based on ambient brightness.
GNU General Public License v3.0
728 stars 27 forks source link

org.freedesktop.PowerManagement.Inhibit was not provided by any .service files #76

Closed anuvc closed 5 years ago

anuvc commented 5 years ago

I am getting the following message when I'm starting clight

inhibit_check(): The name org.freedesktop.PowerManagement.Inhibit was not provided by any .service files
PowerManagement inhibition appears to be unsupported.

I understand that there is a fallback in case Inhibit is not found, however I would like to know how to actually solve the issue.

I could not find a solution to that anywhere on the internet or your documentation. It would be good if you can add a section on how to solve the issue.

mindrunner commented 5 years ago

Funny, we created the same ticket at the same time...

77

FedeDP commented 5 years ago

Hi @beanbagwarrior !

Are you facing any issue (eg: dimmer kicks in while watching a movie)? Because that log does not mean that PowerManagegement won't work; it means that at the time clight starts, no PowerManagement API is appeared on dbus yet. But clight still adds a match (to be notified) on PowerManagement API, thus if it later appears, clight is supporting it (EDIT: look here)

Hi @mindrunner, welcome back! :) Are you using a DE? Or wm? In your case it seems PowerManagement dbus service is not appearing at all. It is up to your DE to provide that dbus interface.

mindrunner commented 5 years ago

I am using awesome-wm on arch linux.

If I install mate-power-manager and have it running, I see the same thing in my log.

FedeDP commented 5 years ago

If I install mate-power-manager and have it running, I see the same thing in my log.

And is dimmer kicking in while watching a movie?

EDIT: quickly digging into mate-power-manager code revelead it does not provide org.freedesktop.PowerManagement API (i can be wrong though, it was just a very quick lookup). Can you try with xfce4-power-manager ?

mindrunner commented 5 years ago

same problem with xfce4-power-manager. I also do not understand why I would need that. Isn't clight the kind of power management application (dimming, gamma, etc) which needs to be inhibited? So why is not clight exposing this interface to make vlc, chrome, etc register direclty there and then adjust brightness and gamma to ne "movie-optimized" values.

Don't get the point, why I need another power manager to achieve that.

anuvc commented 5 years ago

Thanks @FedeDP, I just tested it out, it does not seem that the screen is dimming while watching a movie or a YouTube video.

@mindrunner Haha, strange coincidence ;)

Not closing the thread for @mindrunner 's issue

mindrunner commented 5 years ago

Just double checked:

open youtube, play video start clight screen dimms

Expected behaviour: screen stays on 100% due to video playback

FedeDP commented 5 years ago

@beanbagwarrior
That log message is quite misleading though, i may fix that!

@mindrunner Clight is not a power manager: it is a screen backlight/gamma/dimming/dpms tool. It is not up to it to provide a system power management interface like org.freedesktop.PowerManagement.

open youtube, play video start clight screen dimms

Did you restart your system after installing xfce4-power-manager? (just to be sure it is actually up and running...) and what does busctl --user introspect org.freedesktop.PowerManagement.Inhibit /org/freedesktop/PowerManagement/Inhibit org.freedesktop.PowerManagement.Inhibit output?

mindrunner commented 5 years ago

Yes, the power manager is running.

Failed to introspect object /org/freedesktop/PowerManagement/Inhibit of service org.freedesktop.PowerManagement.Inhibit: The name org.freedesktop.PowerManagement.Inhibit was not provided by any .service files
FedeDP commented 5 years ago

It seems xfce4 too does not support it... it is really weird though! Here is some very old post that states that xfce does not support it though. I found this that does support this interface but unfortunately is not even on AUR. You can try with gnome-power-manager too.

mindrunner commented 5 years ago

I installed the gnome-power-manager as well. But it seems, there is no binary to run. :(

It's kind of frustrating, that power management in Linux is still pain in the ass...

FedeDP commented 5 years ago

Unfortunately it seems org.freedesktop.PowerManagement.Inhibit interface is not as widely supported as i though, being it a freedesktop standard.

I may try to provide that interface myself within Clight as you suggested (where not already available).

mindrunner commented 5 years ago

Cool, that could really help I think.

FedeDP commented 5 years ago

Btw it seems at least xfce4-power-manager provides it: https://github.com/xfce-mirror/xfce4-power-manager/blob/master/src/org.freedesktop.PowerManagement.Inhibit.xml; i don't know why it does not appear on your system.

mindrunner commented 5 years ago

Yeah, I saw that as well. But can't get it working on my system. :(

ochosi commented 5 years ago

Btw it seems at least xfce4-power-manager provides it: https://github.com/xfce-mirror/xfce4-power-manager/blob/master/src/org.freedesktop.PowerManagement.Inhibit.xml; i don't know why it does not appear on your system.

Yes, xfce4-power-manager does provide the inhibitor and it also works. You can call it with d-feet or gdbus call.

This works fine for me: gdbus introspect --session --dest org.freedesktop.PowerManagement --object-path /org/freedesktop/PowerManagement/Inhibit

mindrunner commented 5 years ago

Works for me, whereas clight still gives me the same warning:

[le@w530]: ~>$ gdbus introspect --session --dest org.freedesktop.PowerManagement --object-path /org/freedesktop/PowerManagement/Inhibit
node /org/freedesktop/PowerManagement/Inhibit {
  interface org.freedesktop.DBus.Properties {
    methods:
      Get(in  s interface_name,
          in  s property_name,
          out v value);
      GetAll(in  s interface_name,
             out a{sv} properties);
      Set(in  s interface_name,
          in  s property_name,
          in  v value);
    signals:
      PropertiesChanged(s interface_name,
                        a{sv} changed_properties,
                        as invalidated_properties);
    properties:
  };
  interface org.freedesktop.DBus.Introspectable {
    methods:
      Introspect(out s xml_data);
    signals:
    properties:
  };
  interface org.freedesktop.DBus.Peer {
    methods:
      Ping();
      GetMachineId(out s machine_uuid);
    signals:
    properties:
  };
  interface org.freedesktop.PowerManagement.Inhibit {
    methods:
      @org.freedesktop.DBus.GLib.Async("")
      Inhibit(in  s application,
              in  s reason,
              out u cookie);
      UnInhibit(in  u cookie);
      HasInhibit(out b has_inhibit);
      GetInhibitors(out as inhibitors);
    signals:
      HasInhibitChanged(b has_inhibit_changed);
    properties:
  };
};
[le@w530]: ~>$ clight 
[...]
Trying to start INHIBIT module as its USERBUS dependency was loaded...
inhibit_check(): The name org.freedesktop.PowerManagement.Inhibit was not provided by any .service files
FedeDP commented 5 years ago

Damn, i forgot to reply!

Works for me, whereas clight still gives me the same warning:

As i already said, that warning does not mean that clight is not binding on "HasInhibitChanged" signal. If inhibition does not work in Clight, it means xfce power manager is not sending "HasInhibitChanged" signal on dbus.

I am still trying to figure out a better solution; i don't really want to fully implement org.freedesktop.ScreenSaver dbus interface, as it does not really belong in Clight (ie: clight is not a screensaver/screen locker). But org.freedesktop.ScreenSaver does not have any "HasInhibitChanged" signal, thus i cannot know when a ScreenSaver.Inhibit call is made, thus i cannot intercept them to pause DIMMER module.

On the other hand, org.freedesktop.PowerManagement interface is more about inhibiting power management functions, eg: suspend, hibernate etc etc. This is the interface that eg: your torrent client uses to inhibit suspend while a torrent is downloading. While it works within Clight as it exposes a nice "HasInhibitChanged", letting us intercept Inhibition states, it is kinda stupid to use it.

Finally, there is MPRIS dbus interface. We could match on "PlaybackStatus" property. This is probably the cleanest road, but last time i poked around it, i could not make it work.

mindrunner commented 5 years ago

Ok, interesting. I would assume, that clight should kind-of behave like a screensaver.

However, this does not seem to work reliabliy anyways. Watching movies with VLC will prevent my screensaver from locking. But browserbased watching (youtube, netflix, plex, etc) does not prevent my screensaver from locking. So not an optimal solution... :/

FedeDP commented 5 years ago

At least chromium and firefox do send "org.freedesktop.ScreenSaver.Inhibit", thus they should inhibit DPMS/dimmer while eg: watching a movie on youtube/netflix.

Yes Clight kinda is a ScreenSaver; i could try to provide a inhibit/unhinibit only interface in clight, but what would happen when clight is run inside a full DE (eg: gnome/kde) that already provides that API through they powermanagement daemons? Moreover, there is so little documentation about that bus interface: https://people.freedesktop.org/~hadess/idle-inhibition-spec/re01.html.

mindrunner commented 5 years ago

At least chromium and firefox do send "org.freedesktop.ScreenSaver.Inhibit", thus they should inhibit DPMS/dimmer while eg: watching a movie on youtube/netflix.

I am using lightdm, awesome-wm, xautolock and i3lock. chromium and firefox are not able to prevent my lockscreen from triggering. I have no idea why is that....

but what would happen when clight is run inside a full DE (eg: gnome/kde) that already provides that API through they powermanagement daemons?

What would you expect to happen? I assume, that KDE, GNOME, etc are using the same interfaces, since they are the "standard". Not sure, where this could interfere.

FedeDP commented 5 years ago

What would you expect to happen? I assume, that KDE, GNOME, etc are using the same interfaces, since they are the "standard". Not sure, where this could interfere.

I mean, if clight starts to offer org.freedesktop.ScreenSaver server API (just like these DEs do), the first to start will take ownership of that dbus interface, and i am pretty sure it would not be Clight :)

mindrunner commented 5 years ago

Why does clight need to be the server? It should just listen / poll for either (allowed to lock, or not alloed to lock)

Maybe I have a total misunderstanding of things, sorry. I am confused.

FedeDP commented 5 years ago

Mmh no problem, let's start from scratch :)

Now, we want clight to be another server. But there can be only one org.freedesktop.ScreenSaver server in a user session.

FedeDP commented 5 years ago

Moreover, only server knows that a inhibition has been requested, as in org.freedesktop.ScreenSaver API there is no signal sent whenever an application requests an inhibition.

FedeDP commented 5 years ago

@mindrunner As you suggested, indeed org.freedesktop.ScreenSaver is the most compliant solution, and probably the best among all.

In commits 757ab602491f620f8ea7db436b702e3b73ef97a2 and 6258ee4af28ec3bf083a456743a9cc47c5082a88 (libmodule branch) i started a port to provide this freedesktop specification inside Clight.

It should go like this: if org.freedesktop.ScreenSaver API is available (ie: Clight can bind on it), Clight will take its ownership offering "Inhibit" and "UnInhibit" methods. Else, well you're out of luck, and you'll have to manually inhibit screen dimmer or maybe through a script started together with your video player, eg:

busctl --expect-reply=false --user call org.clight.clight /org/clight/clight org.clight.clight Inhibit "b" true && mpv

Old org.freedesktop.PowerManagement API support has been completely dropped and conf option to avoid inhibit management has been dropped too (i always found it rather useless, as it does not harm anything to leave it on, it just offers a much more pleasant experience).

So, summing it up:

There is no average case :) Unfortunately i think we cannot provide a better experience than this...

mindrunner commented 5 years ago

Now, we want clight to be another server. But there can be only one org.freedesktop.ScreenSaver server in a user session.

Wonder whats the design decision behind that. Sounds quite restrictive...

Will go through the rest of your comments soon and do some testing. Thanks for the nice clarification

FedeDP commented 5 years ago

Wonder whats the design decision behind that. Sounds quite restrictive...

Well, let's think about it: when eg: chromium calls org.freedesktop.ScreenSaver through dbus, dbus needs to know to whom this request should be forwarded; it means that every interface name is unique.

Will go through the rest of your comments soon and do some testing. Thanks for the nice clarification

Unfortunately it is not super easy to test it out: clight libmodule branch requires an unreleased version of libmodule (libmodule built from git master) and an unreleased version of Clightd (clightd built from libmodule5 branch).

mindrunner commented 5 years ago

Well, let's think about it: when eg: chromium calls org.freedesktop.ScreenSaver through dbus, dbus needs to know to whom this request should be forwarded; it means that every interface name is unique.

Subscribers usually do not need to be unique. Multiple instances can subscribe to a bus to receive notifications. This is what buses were invented. Anyways, there were probably reasons and this is not the right place to discuss I suppose.

Unfortunately it is not super easy to test it out: clight libmodule branch requires an unreleased version of libmodule (libmodule built from git master) and an unreleased version of Clightd (clightd built from libmodule5 branch).

Alright. I am caught up with other stuff anyways at the moment. Any ETA when this can be on stable? Or a easily testable version?

FedeDP commented 5 years ago

Subscribers usually do not need to be unique. Multiple instances can subscribe to a bus to receive notifications. This is what buses were invented. Anyways, there were probably reasons and this is not the right place to discuss I suppose.

Yes! But Clight is not subscribing to any Signal, as org.freedesktop.ScreenSaver API has no public signals about whether an inhibitions has been requested; that is the opposite of org.freedesktop.PowerManagement API that had a nice "Inhibited" signal.

Thus, Clight must provide and implement the ScreenSaver specification on its own, because it cannot subscribe to any signal. Hopefully i explained myself this time :)

Any ETA when this can be on stable? Or a easily testable version?

I'd say as soon as i find some time :) That's the roadmap:

Here it will be very easy to test it! Then a couple of weeks of public testing and hopefully a release. I hope to release Clight and Clightd 4.0 early october.

mindrunner commented 5 years ago

Thus, Clight must provide and implement the ScreenSaver specification on its own, because it cannot subscribe to any signal. Hopefully i explained myself this time

Well, I suppose this is one of the reasons why Linux desktops are still not ready for the mainstream... Anyways, also this is another discussion which should not be here....

Thanks for the input! Let me know when the testing build is available! Exciting to try it out.

FedeDP commented 5 years ago

The work is now in master. It does require libmodule 5.0.0 though (released but unavailable yet on AUR to avoid breaking current clight/clightd installations).

mindrunner commented 5 years ago

Hmm, so we need a libmodule-git? What is the preferred way of getting this going on arch?

FedeDP commented 5 years ago

We need libmodule 5.0.0 and clightd-git. Well, about clight-git and clightd-git it's quite easy as there are respective packages. About libmodule, you can find an updated PKGBUILD in its repository: https://github.com/FedeDP/libmodule/blob/master/Extra/Arch/PKGBUILD. You can use that PKGBUILD to build libmodule 5.0.0 :)

mindrunner commented 5 years ago

Cool, thanks. Got it running. :) Lets see how it goes :)

mindrunner commented 5 years ago

Seeing this in my log. What is "My SDL application"?

Dropped ScreenSaver inhibition held by cookie: 719885386.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 1649760492
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 1649760492.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 596516649
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 596516649.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 1189641421
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 1189641421.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 1025202362
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 1025202362.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 1350490027
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 1350490027.
ScreenSaver inhibition disabled.
Being resumed.
Being resumed.
New ScreenSaver inhibition held by My SDL application: Playing a game. Cookie: 783368690
ScreenSaver inhibition enabled.
Being paused.
Being paused.
Dropped ScreenSaver inhibition held by cookie: 783368690.
FedeDP commented 5 years ago

It is a string the application passes to org.freedesktop.ScreenSaver Inhibit method to identify itself. It should be a SDL game I guess, that is inhibiting your ScreenSaver! SDL is a graphic library.

FedeDP commented 5 years ago

Found this: https://github.com/ValveSoftware/steam-for-linux/issues/5532!

mindrunner commented 5 years ago

Yes, found that as well. But since my steam is always up to date (as everything else), I wonder why that happens on my box. It was supposed to be fixed already. However, I just updated my system and after a reboot clightd dies not start anymore:

-- A start job for unit clightd.service has finished with a failure.
-- 
-- The job identifier is 3361 and the job result is failed.
Sep 12 12:44:52 w530 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd comm="systemd" exe="/usr/lib>
Sep 12 12:44:52 w530 kernel: audit: type=1130 audit(1568313892.774:265): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd >
Sep 12 12:44:53 w530 rslsync[1036]: [20190912 12:44:53.024] 16TunnelConnection[0x00007f04300264f0]: received ping
Sep 12 12:44:58 w530 systemd[1]: clightd.service: Service RestartSec=5s expired, scheduling restart.
Sep 12 12:44:58 w530 systemd[1]: clightd.service: Scheduled restart job, restart counter is at 13.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Automatic restarting of the unit clightd.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Sep 12 12:44:58 w530 systemd[1]: Stopped Bus service to manage various screen related properties (gamma, dpms, backlight).
-- Subject: A stop job for unit clightd.service has finished
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A stop job for unit clightd.service has finished.
-- 
-- The job identifier is 3474 and the job result is done.
Sep 12 12:44:58 w530 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd comm="systemd" exe="/usr/lib>
Sep 12 12:44:58 w530 kernel: audit: type=1130 audit(1568313898.021:266): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd >
Sep 12 12:44:58 w530 kernel: audit: type=1131 audit(1568313898.021:267): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd >
Sep 12 12:44:58 w530 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd comm="systemd" exe="/usr/lib/>
Sep 12 12:44:58 w530 systemd[1]: Starting Bus service to manage various screen related properties (gamma, dpms, backlight)...
-- Subject: A start job for unit clightd.service has begun execution
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit clightd.service has begun execution.
-- 
-- The job identifier is 3474.
Sep 12 12:44:58 w530 clightd[5980]: /usr/lib/clightd/clightd: error while loading shared libraries: libddcutil.so.0: cannot open share>
Sep 12 12:44:58 w530 systemd[1]: clightd.service: Main process exited, code=exited, status=127/n/a
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- An ExecStart= process belonging to unit clightd.service has exited.
-- 
-- The process' exit code is 'exited' and its exit status is 127.
Sep 12 12:44:58 w530 systemd[1]: clightd.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- The unit clightd.service has entered the 'failed' state with result 'exit-code'.
Sep 12 12:44:58 w530 systemd[1]: Failed to start Bus service to manage various screen related properties (gamma, dpms, backlight).
-- Subject: A start job for unit clightd.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit clightd.service has finished with a failure.
-- 
-- The job identifier is 3474 and the job result is failed.
Sep 12 12:44:58 w530 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd comm="systemd" exe="/usr/lib>
Sep 12 12:44:58 w530 kernel: audit: type=1130 audit(1568313898.027:268): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=clightd >
Sep 12 12:45:00 w530 rslsync[1036]: [20190912 12:45:00.777] 16TunnelConnection[0x00007f043018c860]: received ping
lines 1502-1575/1575 (END)
FedeDP commented 5 years ago

It seems libddcutil version was bumped (probably ddcutil was updated on aur). You need to re-install clightd-git in order to fix!

mindrunner commented 5 years ago

Shouldn't pacman rebuild thos packages automatically to prevent the break? Anyways, rebuilding clightd-git did not help.

FedeDP commented 5 years ago

Did you reboot too? This is relevant part from your log:

Sep 12 12:44:58 w530 clightd[5980]: /usr/lib/clightd/clightd: error while loading shared libraries: libddcutil.so.0: cannot open share>

Shouldn't pacman rebuild thos packages automatically to prevent the break?

Not for AUR packages; it is done by Arch devs, thus it is only effective for arch repositories.

mindrunner commented 5 years ago

Ok, understand. Did not reboot after rebuild. Will do that later!

mindrunner commented 5 years ago

Sep 12 12:44:58 w530 clightd[5980]: /usr/lib/clightd/clightd: error while loading shared libraries: libddcutil.so.0: cannot open share>

Ha, thank you. I went through the systemd log 3 times and did not see that line... Its on me. Stupid questions

FedeDP commented 5 years ago

You're very welcome :)

mindrunner commented 5 years ago

I reinstalled everything today (libmodule-5, clightd-git clight-git) and I am getting this when I try to start clight:

[le@w530]: ~/src/libmodule/Extra/Arch>$ clight
Bad file descriptor
A lock is present on /home/le/.local/share/clight/clight.log. Another clight instance running?

After a mkdir -p /home/le/.local/share/clight, the application is starting.

FedeDP commented 5 years ago

Thanks, nice catch! I will fix it asap!

mindrunner commented 5 years ago

Cheers.

Unfortunately, the inhibit seems nonfunctional here. (Already posted that into another thread https://github.com/FedeDP/Clight/issues/81) How can we debug?

FedeDP commented 5 years ago

I'll answer there!

FedeDP commented 5 years ago

I just pushed a commit that fixes "/ScreenSaver" (instead of /org/freedesktop/ScreenSaver) issue. Moreover, when org.freedesktop.ScreenSaver bus name is already owned by some other service, clight will now gracefully fallback at monitoring it, just like busctl --monitor org.freedesktop.ScreenSaver does. This way it can still receive updates about ScreenSaver inhibition and works flawlessly!