RFC: idle protocol

[Peter Hutterer]

On Wed, Dec 09, 2015 at 08:17:40AM +0100, Martin Graesslin wrote:
> On Wednesday, December 9, 2015 4:19:12 PM CET Peter Hutterer 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)
> > > 
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <protocol name="idle">
> > > 
> > >   <copyright><![CDATA[
> > >   
> > >     Copyright (C) 2015 Martin Gr????lin
> > >     
> > >     This program is free software: you can redistribute it and/or modify
> > >     it under the terms of the GNU Lesser General Public License as
> > >     published by
> > >     the Free Software Foundation, either version 2.1 of the License, or
> > >     (at your option) any later version.
> > >     
> > >     This program is distributed in the hope that it will be useful,
> > >     but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > >     GNU Lesser General Public License for more details.
> > >     
> > >     You should have received a copy of the GNU Lesser General Public
> > >     License
> > >     along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > >   
> > >   ]]></copyright>
> > >   <interface  name="org_kde_kwin_idle" version="1">
> > >   
> > >       <description summary="User idle time manager">
> > >       
> > >         This interface allows to monitor user idle time on a given seat.
> > >         The interface allows to register timers which trigger after no
> > >         user activity was registered on the seat for a given interval. It
> > >         notifies when user activity resumes.
> > you need to describe what classifies as "user activity".
> 
> something like "after no input events with a new timestamp"? I'm always bad at 
> writing documentation ;-)

yeah, but you'll need to figure out what you want too. does this include
input events as seen on the protocol, as handled by the compositor, does it
include input events not otherwise handled as input (e.g. lid switch), etc.
it's a lot easier to bike-shed when these things are already filled in :)
 
> > 
> > >       <event name="idle">
> > >       
> > >           <description summary="Triggered when there has not been any user
> > >           activity in the requested idle time interval"/>>       
> > >       </event>
> > 
> > what happens when the idle time has been exceeded by the time the request is
> > processed? or does it only trigger from time-of-request + idletime? if the
> > former, you need to detail how the compositor is supposed to keep track of
> > this.
> 
> It's the latter.

right, this then brings up the interesting use-case of idle times firing
randomly across the system rather than simultaneously.
e.g. client A sets a timer for 5 min, client B sets a timer for 5 min, but
a minute later. Those two timers won't fire at the same time now which could
lead to UI inconsistencies.

> > 
> > >       <event name="resumed">
> > >       
> > >           <description summary="Triggered on the first user activity after
> > >           an idle event"/>>       
> > >       </event>
> > 
> > same here, more information is needed, can this be triggered before an idle
> > event?
> 
> no. I would consider this as a possible security problem if it were possible 
> to get notified on each input event.

you get that security problem anyway if you set the timeout to 1 ms, that
way you can pretty much listen to the keystroke timing. What I was referring
to is: if you set a timeout for X and the compositor is already at idletime
X + N, do get a resume event when resumed. This goes in hand with the above
obviously and whether you can immediately get an idle event when the timer
is requested rather than waiting..

more questions: is there a minimum timeout? does the compositor guarantee
that the idle timer fires, or that it fires within Xms of the timeout?

Cheers,
   Peter