RFC: idle protocol

[Bryce Harrington]

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]; 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?

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.

Bryce



1: https://patchwork.freedesktop.org/patch/66111/

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iEYEABECAAYFAlZm1zUACgkQqVXwidMiVrpNwgCgm5MbM3zGsaL/qJlj1bpiJ+Qa
> T3sAn3B4HgURcTEkmmbQ5Xz3uVI4Q+rP
> =0WH5
> -----END PGP SIGNATURE-----


> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel