Re: RSIBreak / KIdleTime on Wayland

2020-11-16 Thread Dominik Waurenschk
> > Yes, I meant that progress bar.
> > I've had that 1s idle timer idea as well, unfortunately after writing this, 
> > but thank you for confirming that this would indeed work.
> > I will give that a try and if I can get RSIBreak to a working state on 
> > wayland submit a PR for it.
>
> Excellent, thank you very much.
> Please do please reach out if there are any questions with regards to the 
> wayland side.
>
> David

So, I implemented it this way (least invasive to RSIBreak):
If the user was idle for a second (using a KIdleTime timeout), I start my own 
idle time counter (counter++ every second).
Then I catch the next resume event (next user input) and reset my counter to 0.

Now here's some things I found:
1) It works just fine in X.

2) It works with XWayland, but only detects user activity if the user makes an 
input to an XWayland window.
   This means RSIBreak will think the user is idle if using a native wayland 
application.
   On a KDE Plasma Wayland session, RSIBreak is started as an XWayland 
application by default.

3) It works okay if RSIBreak is started as a native Wayland application 
(QT_QPA_PLATFORM=wayland).
   All input is detected, on native and XWayland windows.
   But: It takes about 5-10 seconds of me not doing any inputs for the idle 
timeout to be called, instead of the 1 second timeout I requested.
   (the resume event is emitted immediately though, it is just the idle timout 
that is slow)

So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland 
works.
Thank you,
Dominik

signature.asc
Description: OpenPGP digital signature


Re: RSIBreak / KIdleTime on Wayland

2020-11-16 Thread Dominik Waurenschk
> > 2.  It works with XWayland, but only detects user activity if the user 
> > makes an input to an XWayland window.
> Yeah, that's expected. We only send things to X when an X app has focus.
> Changing this behaviour is not an option. I don't think this is a viable 
> setup option to support.
> > RSIBreak is started as an XWayland application by default.
> That shouldn't be the case. Are you on OpenSuse by any chance?

Alright, just checking if that is intended behaviour.
Yes, I am indeed on OpenSuse, so I guess that's some kind of config error on my 
end. 

No need to worry about this case then.

> > 3.  It works okay if RSIBreak is started as a native Wayland application 
> > (QT_QPA_PLATFORM=wayland).
> > All input is detected, on native and XWayland windows.
> > But: It takes about 5-10 seconds of me not doing any inputs for the 
> > idle timeout to be called, instead of the 1 second timeout I requested.
> > (the resume event is emitted immediately though, it is just the idle 
> > timout that is slow)
> Indeed:
> // less than 5 sec is not idle by definition
> timer->setInterval(qMax(timeout, 5000u));
>
> In kwayland-server/src/server/idle_interface.cpp
> I have no objections to changing this.
> 

> David

Thanks for the information, and the merge request :)

Dominik

signature.asc
Description: OpenPGP digital signature


Re: RSIBreak / KIdleTime on Wayland

2020-11-16 Thread David Edmundson
change made:
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133


Re: RSIBreak / KIdleTime on Wayland

2020-11-16 Thread David Edmundson
>If the user was idle for a second (using a KIdleTime timeout), I start my own 
>idle time counter (counter++ every second).
>Then I catch the next resume event (next user input) and reset my counter to 0.

That sounds like what I had in mind.

> 2) It works with XWayland, but only detects user activity if the user makes 
> an input to an XWayland window.

Yeah, that's expected. We only send things to X when an X app has focus.
Changing this behaviour is not an option. I don't think this is a
viable setup option to support.

>RSIBreak is started as an XWayland application by default.
That shouldn't be the case. Are you on OpenSuse by any chance?

>
> 3) It works okay if RSIBreak is started as a native Wayland application 
> (QT_QPA_PLATFORM=wayland).
>All input is detected, on native and XWayland windows.
>But: It takes about 5-10 seconds of me not doing any inputs for the idle 
> timeout to be called, instead of the 1 second timeout I requested.
>(the resume event is emitted immediately though, it is just the idle 
> timout that is slow)

Indeed:

// less than 5 sec is not idle by definition
timer->setInterval(qMax(timeout, 5000u));

In kwayland-server/src/server/idle_interface.cpp
I have no objections to changing this.

David

>
> So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland 
> works.
> Thank you,
> Dominik


Re: RSIBreak / KIdleTime on Wayland

2020-11-15 Thread Dominik Waurenschk
> > > So do you think it makes sense to have the function return some form or 
> > > error instead of just returning 0, or is there a good reason it is not 
> > > doing that already?
> I don't think it helps with a lot, you need to change clients to
> handle the error, at which point we've not really solved a lot. If
> you're going to use the addIdleTimeout API you may as well do it
> everywhere. It is considerably lighter on X11 too. 

> Like Albert suggested, a capabilities flag could make sense.

Now that it was mentioned, I agree that having some way of checking if this 
feature works (like a capability flag) is a better idea than changing the 
expected behaviour of the function.

> > RSIBreak is unable to count down in wayland, after 1 second it always 
> > resets its timer.
> Just to make sure we're talking about the same thing: Is it when you
> have a shortbreak set after N minutes and you get a "please relax for
> 20seconds" with a progress bar?
> 

> If so, simplest option is to start a 1s idletime timer. We don't need
> to know how long we've been idle via polling, just if/when we're
> interrupted during the 20s countdown.
> David

Yes, I meant that progress bar.
I've had that 1s idle timer idea as well, unfortunately after writing this, but 
thank you for confirming that this would indeed work.
I will give that a try and if I can get RSIBreak to a working state on wayland 
submit a PR for it.

Dominik

signature.asc
Description: OpenPGP digital signature


Re: RSIBreak / KIdleTime on Wayland

2020-11-15 Thread David Edmundson
>
> Yes, I meant that progress bar.
> I've had that 1s idle timer idea as well, unfortunately after writing this, 
> but thank you for confirming that this would indeed work.
> I will give that a try and if I can get RSIBreak to a working state on 
> wayland submit a PR for it.

Excellent, thank you very much.
Please do please reach out if there are any questions with regards to
the wayland side.

David


Re: RSIBreak / KIdleTime on Wayland

2020-11-15 Thread David Edmundson
> I agree, if we can't make the KIdleTime framework work in Wayland there 
> should be a way to query the framework if it's going to work or not.

Just to make sure that's not misread by others; the framework works
for the majority of methods used in the common case, just not this one
polling method.

> > So do you think it makes sense to have the function return some form or 
> > error instead of just returning 0, or is there a good reason it is not 
> > doing that already?

I don't think it helps with a lot, you need to change clients to
handle the error, at which point we've not really solved a lot. If
you're going to use the addIdleTimeout API you may as well do it
everywhere. It is considerably lighter on X11 too.

Like Albert suggested, a capabilities flag could make sense.
At a super bare minimum the documentation needs updating. At the other
extreme we could even deprecate it.

If after trying to port rsibreak to use the event driven API and it
turns out there really is a use case for a polling API, we do still
have the option to start a discussion about extending the relevant
wayland protocol to have such a query mechanism.



>RSIBreak is unable to count down in wayland, after 1 second it always resets 
>its timer.

Just to make sure we're talking about the same thing: Is it when you
have a shortbreak set after N minutes and you get a "please relax for
20seconds" with a progress bar?

If so, simplest option is to start a 1s idletime timer. We don't need
to know how long we've been idle via polling, just if/when we're
interrupted during the 20s countdown.

David


Re: RSIBreak / KIdleTime on Wayland

2020-11-15 Thread Albert Astals Cid
El dissabte, 14 de novembre de 2020, a les 12:46:41 CET, Dominik Waurenschk va 
escriure:
> Hi, I just came across the issue that RSIBreak is unable to count down in 
> wayland, after 1 second it always resets its timer.
> 
> I investigated the code and found that it calls KIdleTime, which in turn 
> calls a platform-specific plugin. 
> 
> In particular, it calls forcePollRequest() to get the current idle time 
> (instead of waiting for a timeout event or similar)
> 
> For Wayland this function prints a warning that this plugin doesn't support 
> polling idle time, but then always returns 0, which RSIBreak later interprets 
> as activity, since it thinks 0 seconds passed, this halting the countdown.
> 
> This plugin in turn uses KWayland::Client::Idle, which does indeed seem to 
> only support timeouts and no getting the actual idle time. So if it is really 
> not possible to count idle time in wayland (I don't know enough about wayland 
> to implement it myself at this time), then I think it would be useful to, 
> instead of only printing a warning to console/log, the function would 
> actually return some type of error code to the caller. (It could return -1, 
> or throw an exception, or similar) 
> 
> 
> So then the caller can react to the fact that polling is not supported, and 
> could perhaps implement a different way of measuring time on that platform. 
> (it could perhaps use its own timer and reset when the platform plugin emits 
> resumingFromIdle, i haven't tried out how this works yet).
> 
> So do you think it makes sense to have the function return some form or error 
> instead of just returning 0, or is there a good reason it is not doing that 
> already?

I agree, if we can't make the KIdleTime framework work in Wayland there should 
be a way to query the framework if it's going to work or not.

CC'ing the frameworks devel list.

Cheers,
  Albert

> 
> Thank you,
> Dominik
>