KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 5:04:09 PM CET René J. V. Bertin wrote:
> > I can say for Wayland as I wrote that recently:
> I'm guessing Wayland will provide a mechanism that's inspired by what Xcb
> provides?

eh no. As I control both the server (hello KWin) and the client (hello 
KWayland) I just designed a protocol which is ideal for KIdleTime.

> 
> > * it will fire if it's hit - there might be a delay which I think doesn't
> > matter in the case of being swapped out.
> 
> Do you mean that the delay is independent of whether or not you're swapped
> out, or that the question of how long the delay is is moot if you are
> (were) swapped out? It will "Fire if it's hit", but what "it" doesn't get
> hit at the configured time but at a later time?

Sorry, but I just don't get your problem here. This all sounds highly 
theoretical to me and is nothing which I considered at all.

The implementation is basically:
* Wayland client registers an idle timeout
* KWayland::Server creates a QTimer
* on each input event the QTimer is restarted
* if the QTimer times out in the Wayland server the Wayland client is notified

Now this includes a few IPC roundtrips which are completely outside the 
control of my code. Like the last step. What do I know when the client will be 
notified by the kernel about it?

> 
> > The Wayland implementation doesn't give a guarantee that if there is an
> > idle time of 5 sec it will be signalled exactly after 5 sec. That's
> > something a non-realtime system cannot provide.
> 
> Of course not. But that doesn't mean it is pointless to try to minimise the
> delay (for instance by polling ;))

There is absolutely zero polling in the Wayland implementation!

> And I really don't see the point in providing a framework for this (and
> basically only this) if it's not going to try to be as versatile as
> possible. It can and should aim to avoid hogging any resources in the
> default configuration.

Repeat after me: no polling! I mean that: NO POLLING! Don't add code which 
polls. Don't do that.

NO POLLING!

If you cannot do that on OSX, I really think it's better to not provide it. If 
you think it's unfair that there is a backend for X11 which performs polling, 
then I'm going to delete the XScreenSaver based one.

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://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151117/c792bd87/attachment.sig>