Re: RSIBreak / KIdleTime on Wayland
> > 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
> > 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
> > 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
> > 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
change made: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133
Re: RSIBreak / KIdleTime on Wayland
change made: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133
Re: RSIBreak / KIdleTime on Wayland
>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
>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
> > > 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
> > > 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
> > 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
> > 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
> 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
> 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
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 >
Re: RSIBreak / KIdleTime on Wayland
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 >
RSIBreak / KIdleTime on Wayland
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? Thank you, Dominik signature.asc Description: OpenPGP digital signature
