On Tue, 04.03.14 01:06, Timothée Ravier (sios...@gmail.com) wrote: > > On 03/03/2014 14:28, Àlex Fiestas wrote: > > On Friday 28 February 2014 02:28:20 Lennart Poettering wrote: > >> They should just invoke the methods. If they get > >> org.freedesktop.DBus.Error.UnknownMethod, > >> org.freedesktop.DBus.Error.UnknownObject or > >> org.freedesktop.DBus.Error.UnknownInterface back they should assume that > >> logind is too old and doesn't support the call. (Actually, to make this > >> really robust, they should just treat any error like that). > >> > >> Check for features by trying to make use of them. Don't check for > >> version numbers. > > The problem was that long ago logind supported suspend (methods were in the > > bus) but they did not work, at least not for opensuse so that work around > > was > > added. > > > > This code will certainly die in the near future. > > I'm working on fixing this for KDE > (https://git.reviewboard.kde.org/r/116527/). But now that I've looked at > it little bit closer I think I may understand why they did version checks: > > As far as I understand, between v183 (d889a2069a87e4617b32dd) and v198 > (314b4b0a68d9ab35de98192), PrepareForSleep signal is sent before > suspending, but no signal is sent on resume, thus one must use upower to > get this info; From v198 and onward, PrepareForSleep signal is also sent > on resume, thus no need for upower anymore. > > Am I correct here? Did I miss something? Are there are any other > solutions than checking for the version number to know if > PrepareForSleep will be sent on resume? Should we just give up trying to > support versions of systemd older than 198 (for systemd-based systems)?
So, the old interface really didn't support any notification for system resume at all. We always assumed the kernel would eventually provide something for this, but we came to the conclusion that even if the kernel would provide userspace with a notification scheme for this (which it still doesn't do to this point) we should probably distuingish between low-level suspends (possibly done by the kernel itself with aggressive kernel-level auto-suspend), from high-level suspends managed by logind. So, this wasn't really a compat breakage, since we just generated signals that previously were only available for specific clients so that all clients would get them. However, that certianly doesn't help userspace apps like yours, since for them it cannot be determined whether they are running on a system that only generates PrepareForSleep() sometimes, or always... I'd probably recommend using upower when it is there (and support for it is compiled in), and then use logind as a fallback otherwise. That should make your code work with any system. Or alternatively, just declare that you require 198 at least... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel