Re: Power Management and Inhibition by Applications
On Wed, Jan 16, 2019 at 10:08 PM Matthieu Gallien < gallien.matth...@gmail.com> wrote: > Hello, > > I am trying to work on a feature request to add the ability to suppress > laptop > sleep when playing music. > > Currently, Juk is doing it via dbus calls to > "org.kde.Solid.PowerManagement". > > I also had a look to Solid frameworks and the power classes that add an > asynchronous way to do that. > Currently, the Solid framework only conditionally provides those features > and > it seems distributions (at least Debian) do not always build it. > > I am also unsure about the current recommended solution that would work > for > most desktop environments. > > What would be the best way forward ? > > I can also see some other features that could make sense to provide in > libraries that music players could use (lyrics fetching, album art > fetching, > ...). This could be in a dedicated framework to help build media players. > > Best regards > > -- > Matthieu Gallien > > > Solid only does this conditionally because it was a WIP work that never was finished. I'd say having nice async API in solid, kdbusaddons or wherever could be useful. Aleix
Re: Power Management and Inhibition by Applications
Hello, On mercredi 23 janvier 2019 08:52:26 CET Kai Uwe Broulik wrote: > Hi, > > > I had thought that would only inhibit the screensaver instead of automatic > > sleep. > > KScreenLocker (previously KSMServer) that owns the > org.freedesktop.ScreenSaver interface tells PowerDevil to keep the > screen on when screensaver is inhibited. It makes no sense to prevent > the screen from locking (ie. keep the desktop visible) but then allow > the screen to turn off, having the same effect: hiding the desktop. > > I did a quick test and in case I inhibit through > > org.freedesktop.ScreenSaver interface, the battery applet does not > > indicate any inhibit whereas through > > org.freedesktop.PowerManagement.Inhibit indicates that an inhibition is > > valid. > It should and it does here. Note that PowerDevil only enforces > inhibitions after five seconds to prevent short transient inhibitions > (e.g. web browsers block suspend when playing audio which could also > lead to short notification sounds prolonging the time until suspend) I have restarted my session and it is now working. Sorry for that. I also had somehow missed that interface. It looks to me like it is also supported by other desktop environments. Do you know if it is really the case ? > > I wonder if I should not instead make usage of the Inhibit mechanism from > > logind coupled with powerdevil. I am not sure if this is desired. > > It is and I would love that, I just haven't had the time to implement it. > > Also I'm a bit tired of adding yet another inhibition interface (we > already have like three or four of them) of the "but this time, I > promise, it will be perfect!!" kind. Last time I checked logind didn't > offer signals for when an inhibition was added/removed, so the "xyz is > curently blocking PM" in Battery Monitor might not be possible anymore > this way. > > Cheers > Kai Uwe My understanding of the current mechanism in Logind is that except the "systemctl suspend" command, nothing prevent suspend when you add an inhibitor blocking sleep. I was hoping for this interface to be the "universal" one that would avoid the need to support many interfaces in an application. As far as I understand, each software wanting to suspend has to check itself for any blocking inhibition for sleep. I can volunteer to add this to Powerdevil if this is deemed useful. I had checked the dbus interface for logind and there is still no any signals to know when an inhibition is added or removed. Best regards -- Matthieu Gallien
Re: Power Management and Inhibition by Applications
Hi, I had thought that would only inhibit the screensaver instead of automatic sleep. KScreenLocker (previously KSMServer) that owns the org.freedesktop.ScreenSaver interface tells PowerDevil to keep the screen on when screensaver is inhibited. It makes no sense to prevent the screen from locking (ie. keep the desktop visible) but then allow the screen to turn off, having the same effect: hiding the desktop. I did a quick test and in case I inhibit through org.freedesktop.ScreenSaver interface, the battery applet does not indicate any inhibit whereas through org.freedesktop.PowerManagement.Inhibit indicates that an inhibition is valid. It should and it does here. Note that PowerDevil only enforces inhibitions after five seconds to prevent short transient inhibitions (e.g. web browsers block suspend when playing audio which could also lead to short notification sounds prolonging the time until suspend) I wonder if I should not instead make usage of the Inhibit mechanism from logind coupled with powerdevil. I am not sure if this is desired. It is and I would love that, I just haven't had the time to implement it. Also I'm a bit tired of adding yet another inhibition interface (we already have like three or four of them) of the "but this time, I promise, it will be perfect!!" kind. Last time I checked logind didn't offer signals for when an inhibition was added/removed, so the "xyz is curently blocking PM" in Battery Monitor might not be possible anymore this way. Cheers Kai Uwe
Re: Power Management and Inhibition by Applications
Hello, On samedi 19 janvier 2019 12:19:10 CET Elvis Angelaccio wrote: > On 16/01/19 22:07, Matthieu Gallien wrote: > > Hello, > > > > I am trying to work on a feature request to add the ability to suppress > > laptop sleep when playing music. > > > > Currently, Juk is doing it via dbus calls to > > "org.kde.Solid.PowerManagement". > > > > I also had a look to Solid frameworks and the power classes that add an > > asynchronous way to do that. > > Currently, the Solid framework only conditionally provides those features > > and it seems distributions (at least Debian) do not always build it. > > > > I am also unsure about the current recommended solution that would work > > for > > most desktop environments. > > > > What would be the best way forward ? > > Hi, > the "official" way to achieve that should be a dbus call to the > org.freedesktop.ScreenSaver interface (methods Inhibit and UnInhibit). I had thought that would only inhibit the screensaver instead of automatic sleep. I did a quick test and in case I inhibit through org.freedesktop.ScreenSaver interface, the battery applet does not indicate any inhibit whereas through org.freedesktop.PowerManagement.Inhibit indicates that an inhibition is valid. I wonder if I should not instead make usage of the Inhibit mechanism from logind coupled with powerdevil. I am not sure if this is desired. I would forward inhibit request to logind and checks existing inhibition before allowing powerdecil to suspend. > > I can also see some other features that could make sense to provide in > > libraries that music players could use (lyrics fetching, album art > > fetching, ...). This could be in a dedicated framework to help build > > media players. > > > > Best regards > > > > -- > > Matthieu Gallien > > Cheers, > Elvis Best regards
Re: Power Management and Inhibition by Applications
On 16/01/19 22:07, Matthieu Gallien wrote: > Hello, > > I am trying to work on a feature request to add the ability to suppress > laptop > sleep when playing music. > > Currently, Juk is doing it via dbus calls to "org.kde.Solid.PowerManagement". > > I also had a look to Solid frameworks and the power classes that add an > asynchronous way to do that. > Currently, the Solid framework only conditionally provides those features and > it seems distributions (at least Debian) do not always build it. > > I am also unsure about the current recommended solution that would work for > most desktop environments. > > What would be the best way forward ? Hi, the "official" way to achieve that should be a dbus call to the org.freedesktop.ScreenSaver interface (methods Inhibit and UnInhibit). > > I can also see some other features that could make sense to provide in > libraries that music players could use (lyrics fetching, album art fetching, > ...). This could be in a dedicated framework to help build media players. > > Best regards > > -- > Matthieu Gallien > > Cheers, Elvis
Power Management and Inhibition by Applications
Hello, I am trying to work on a feature request to add the ability to suppress laptop sleep when playing music. Currently, Juk is doing it via dbus calls to "org.kde.Solid.PowerManagement". I also had a look to Solid frameworks and the power classes that add an asynchronous way to do that. Currently, the Solid framework only conditionally provides those features and it seems distributions (at least Debian) do not always build it. I am also unsure about the current recommended solution that would work for most desktop environments. What would be the best way forward ? I can also see some other features that could make sense to provide in libraries that music players could use (lyrics fetching, album art fetching, ...). This could be in a dedicated framework to help build media players. Best regards -- Matthieu Gallien
Power Management and Inhibition by Applications
Hello, I am trying to work on a feature request to add the ability to suppress laptop sleep when playing music. Currently, Juk is doing it via dbus calls to "org.kde.Solid.PowerManagement". I also had a look to Solid frameworks and the power classes that add an asynchronous way to do that. Currently, the Solid framework only conditionally provides those features and it seems distributions (at least Debian) do not always build it. I am also unsure about the current recommended solution that would work for most desktop environments. What would be the best way forward ? I can also see some other features that could make sense to provide in libraries that music players could use (lyrics fetching, album art fetching, ...). This could be in a dedicated framework to help build media players. Best regards -- Matthieu Gallien
