On Mon, 2014-03-17 at 12:03 +0700, Antoine Martin wrote: > On 16/03/14 22:36, Antoine Martin wrote: > > On 16/03/14 22:30, Michael Biebl wrote: > >> 2014-03-16 15:54 GMT+01:00 Antoine Martin <anto...@nagafix.co.uk>: > >>> On 16/03/14 21:28, Michael Biebl wrote: > >>> > >>> Newer upower versions no longer emit that signal since this handled by > >>> systemd. > >>> > >>> OK, I hope there a new signal I can listen for? > >> http://www.freedesktop.org/wiki/Software/systemd/logind/ > >> > (snip) > >> > >> Does that help? > > It does! > > I had seen that page like a dozen times, but somehow missed the > > "PrepareForSleep with argument False" everytime. > For reference, I am attaching a sample script which fires when the > system suspends or resumes. > > Are there any reasons not to keep backwards compatibility here? > By that, I mean keeping both the old "upower Resuming" signal as well as > the new "login1 PrepareForSleep" interface. > For one, the old interface is much nicer, widely used, and uses more > sensible and meaningful names for signals.
The old interface was also deprecated. > But more importantly, I don't see why system power events would belong > in the "login manager" at all. A login manager may use power events, it > should not own them. It's a better place than a service that doesn't handle suspend/resume. > For instance, I could be running graphical applications on a systemd > enabled system without necessarily having a login manager installed or > running. And I would still expect to receive power event notification. You always have logind running on a systemd enabled system, it's part of systemd. I think you're confused about what logind is. _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
