expanding the inhibit spec

[Lennart Poettering]

On Thu, 09.01.14 13:08, Ryan Lortie (desrt at desrt.ca) wrote:

> > I mean, I am pretty sure that most other inhibition APIs would also try
> > to record who actually took the lock, and would thus be affected too if
> > you always proxy everything via some other daemon so that everything
> > looks like it came from the very same processs...
> 
> I agree that this is a weakness.  It's a weakness that could be
> addressed by logind implementing this API for itself (or trusting
> forwarded information from gnome-session or other designated
> processes).

logind is not going to listen on session busses. Having trusted code on
untrusted client busses is never going to work.

> > Abstracting this with just the vague idea that maybe one day there might
> > be a second backend, and that then maybe when that day comes it would be
> > better to run that on the session bus sounds just awfully wrong.
> > 
> > So, what precisely are you trying to make work here?
> 
> First, it's a pain for me (with Gtk hat on) to have to test for the
> existence of various D-Bus services in order to decide which one I
> should talk to.  This is the kind of thing we're used to, though... we
> have a bug open about it right now.  I'm using this thread as a way to
> resist adding code complexity on my side about it.

Note that at least on kdbus checking for the presence of logind is a
single simple, synchronous ioctl, nothing more. It cannot get much
simpler than that...

> It's a whole other issue, though, when we start to talk about
> independent app vendors who don't want to use Gtk.  People who want to
> make something in SDL and have it just work.  What do we tell them?  I
> guess we could start by asking them "what is your intended platform?"
> 
> "I don't know.. GNOME?  The freedesktop APIs?  Linux?  systemd-using
> systems?"

How many systems are those currently, and how many are those going to be
in a year or two? I mean, by then the set of systems that have dbus (and
possibly a future fdo inhibitor service) and the set of systems that
have logind is probably going to be identical, no? I mean, if people
avoid logind, aren't they also avoiding dbus?

> It turns out that in order to answer this question I actually have to
> ask another question: "what type of thing are you trying to suspend?"
> 
> If they say "screensaver due to idle", the answer is "GNOME" (because
> logind doesn't handle this).
> 
> If they say "logout, because I have unsaved files", answer again is
> "GNOME".
> 
> If they say "suspend, due to idle" or "suspend, because I want to do
> cleanup tasks" the answer is now "logind" (or "Linux", if we want to
> take the somewhat reasonable approach that logind is universal at least
> for Linux systems).
> 
> This sort of lack of coherence is at the root of what is bothering me. 
> It's bad enough to approach from the standpoint of trying to make Gtk
> work... it's nearly unapproachable from the standpoint of third
> parties.

I can certainly see the problem, but I think an abstract fdo service on
the session bus is not an answer to that.

I mean, if people decide not to use a library that abstracts these
things, like glib (or qt...), then they get to keep both pieces, the
have to deal with the compatibility problems, and the incoherent
interfaces...

I think it would be great if the difference between the major desktops
regarding inhibition locks for screenlock/logout could be dealt with by
agreeing on some common bus interface. With that in place you'd cover >
80% of the cases by just supporting logind and this new session api in
your app.

This would still mean incoherent interfaces, but at least the number of
backends to explicitly support is just 2.

> > > Even that would not make me completely happy, however, because I
> > > couldn't handle all of my inhibit needs there (unless you were willing
> > > to expand the list of things you support inhibiting, for informational
> > > purposes for the session to see).
> > 
> > "things logind supports inhibiting"? what would those be?
> 
> What I meant by this is that logind could start state-tracking for
> things that it doesn't care about itself, such as "logout" or "prevent
> screensaver".  gnome-session could then watch logind to determine which
> flags have been set and decide how to modify its own behaviour based on
> that.
> 
> Note about "screensaver": I am assuming here that applications may want
> to inhibit "idle" for more than one reason.  If I'm downloading a file,
> I may want to inhibit suspend-due-to-idle while still allowing the
> screen to lock.  If I'm playing a video, I probably want to inhibit
> both.

I am vaguely negative about this, but I could be convinced. Can you
explain how precisely you'd assume the API for this would look like in logind?

Lennart

-- 
Lennart Poettering, Red Hat