RFC: idle protocol

[Martin Graesslin]

On Wednesday, December 9, 2015 5:43:13 PM CET Peter Hutterer wrote:
> > > 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 :)

hehe :-)

> 
> > > >       <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.

Not sure whether that's a problem in practice.  When applications register the 
timeouts we can assume that the session is not idle. E.g. user starts chat 
application, so not idle. Given that all timers should fire again at the same 
time.

It's only a problem if the application registers while the session is already 
idle.

> 
> > > >       <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.

yep, I recently changed our implementation to require at least 5 sec. I 
probably should add a security consideration to the description.

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

As just written: our implementation has a minimum timeout.

> does the compositor guarantee
> that the idle timer fires, or that it fires within Xms of the timeout?

In my opinion: no and no.

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/cd6ba14f/attachment.sig>