expanding the inhibit spec

Àlex Fiestas afiestas at kde.org
Sun Jan 12 07:42:59 PST 2014

Having read the whole thread (and about to write the power management support 
for KDE5/Plasma 2) I think we do need a session daemon handling the things 
that are out of logind1 scope and its api must be in fd.o, but I would like to 
avoid duplicating api with it, and even worse end up proxying calls.

The way we have currently implemented logind1 support is just by adding one 
inhibition with description "KDE Handlers this" which sucks since systemd is 
not aware of what applications are inhibiting. This is valuable information we 
must have in systemd in the future and that's why on future releases (KDE5) 
the plan was to talk directly to logind1 whenever possible.

Distributions that don't want to use logind1 can implement a dbus service with 
the same api, maybe we can move the inhibition api to its own service to make 
it more obvious that that api doesn't depend on all the other logind1 

So in short:
+1 to have a common fd.o spec for things that can't be in logind1
-1 to duplicate api with logind1


More information about the xdg mailing list