RFC: idle protocol

[Martin Graesslin]

On Tuesday, December 8, 2015 2:59:38 PM CET Bryce Harrington wrote:
> On Tue, Dec 08, 2015 at 02:12:01PM +0100, Martin Graesslin wrote:
> > Hi Wayland-developers,
> > 
> > at KDE we developed a protocol for our framework kidletime [1]. The idea
> > is to notify Wayland clients when a wl_seat has been idle for a specified
> > time. We use this for example for power management, screen locking etc.
> > But a common use case is also setting a user as away in a chat
> > application.
> > 
> > We think that this protocol can be in general useful for all Wayland based
> > systems. Our current protocol is attached to this mail. Of course for
> > integration into wayland protocols the namespace needs adjustments (I'm
> > open for suggestions).
> > 
> > The reference implementation of the protocol can be found in the KWayland
> > repository (client at [2], server at [3]).
> > 
> > Best Regards
> > Martin Gräßlin
> > 
> > [1] http://inqlude.org/libraries/kidletime.html
> > [2] git://anongit.kde.org/kwayland (path src/client/idle.h and src/client/
> > idle.cpp)
> > [3] git://anongit.kde.org/kwayland (path src/server/idle_interface.h and
> > src/ server/idle_interface.cpp)
> 
> Hi Martin, thanks for proposing this protocol.  You may have seen the
> screensaver inhibition protocol proposed recently[1];

no I hadn't seen this and I'm slightly surprised about a screensaver 
inhibition as that is IMHO a solved problem on DBus level - both on the 
org.freedesktop.ScreenSaver as well on 
org.freedesktop.PowerManagement.Inhibit.

I'll have a look and provide some feedback. Right now from just reading it, I 
don't see why we would want to have a windowing system specific solution while 
we already have a window system agnostic solution.

> this is an area
> I've been poking around at, and it's interesting to see the extension of
> idleness to client activities beyond just screen blanking.
> 
> There had been some discussion about providing a mechanism to fake user
> input, but it felt like maybe that was just a workaround for lacking a
> more fundamental solution to whatever the application wished to do.  For
> instance, some apps do this just to prevent the screensaver from coming
> on such as while something's being shown to the user; for this the
> inhibition functionality is probably a better solution.  I would be
> interested in learning if there are other use cases you have in mind
> where fake user input would be helpful, and inhibition would not be
> feasible as a solution?

A recent case we hit recently were the user activity was needed (on X11) was 
coming from a VT switch which then directly triggered the system suspend as 
the idle timeout was hit. So the solution was to simulate user activity on 
switch back to prevent that from happening.

The main reason for me to implement it, was to provide everything our 
KIdleTime framework used. I didn't see a reason to not provide it as there 
were users for it. Please note that the implementation only simulates user 
activity on the registered timeout and leaves all others unaffected, so that 
process A cannot change the idle timeouts of process B.

> 
> The idle.xml proposed protocol focuses more on user activity at the
> input level; it doesn't proscribe anything with regard to screen
> behavior, and is usable in situations other than screens.  The
> inhibition proposed protocol focuses on display blanking behavior and
> ties into surfaces rather than seats.  But these have an obvious
> relationship.  I'm not sure the two protocols should be merged
> necessarily, but they probably should be designed to fit together
> nicely.
> 
> Essentially we can break the problem space in half.  On the one side we
> have things that generate activity - i.e. seats, but also anything that
> might need to otherwise have to fake user input.  On the other side are
> things that respond to idleness; this would include screensavers/screen
> blanking, obviously, but could be generalized to also cover use cases
> like your chat applications and so on.

After a quick look at the protocol it looks rather orthogonal to me. And 
that's also how it used to be in our implementation: inhibition and idle time 
are two different areas. E.g. our screen locker gets an idle timeout and then 
checks the inhibitions whether it should go idle at all. If you're interested 
in a real world example: https://quickgit.kde.org/?
p=kscreenlocker.git&a=blob&h=43062eaab206951f6c8e0a6636510b5d5f8d08fe&hb=2e6ce72d88be62957afd28e8f6dafc41052635a2&f=ksldapp.cpp

line 188 following

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151209/273d97ba/attachment-0001.sig>