| Summary: | Break never counts down to zero in Wayland | ||
|---|---|---|---|
| Product: | [Applications] rsibreak | Reporter: | Borden <borden_c> |
| Component: | general | Assignee: | Albert Astals Cid <aacid> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | asturm, bugtracking, dominik.waurenschk+kde, ericsbinaryworld, gudvinr+kde, ian.carolan, joelsgp, kde, lukas.kripner, lukasz, meven29, miraj.bhattarai, mjbroek, n.sheibley, qwerty287, toralf.foerster, tusharhero, valdikss, zejdzztegomaila |
| Priority: | HI | Keywords: | wayland-only |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Borden
2020-05-24 20:57:21 UTC
> In Wayland KDE, behaviour is similar EXCEPT when it's time to take a break. The pop-up appears in the top left corner of my screen for some reason, which is irritating but not fatal. This seems like an osd placement related issue. A fix like Kscreen might be in order or how plasma does it. https://phabricator.kde.org/D28916 It might have some side-effect after. FWIW personally i don't really have much stamina to fix this in wayland, so Merge Request more than welcome I have just come across this exact issue myself. I investigated the code and found that RSIBreak calls KIdleTime, which uses a platform-specific plugin to find the idle time. For wayland, this prints a warning to console that the plugin does not support polling idle time (it does support timeouts it seems). But, then it returns 0, which RSIBreak in turn interprets as 0 seconds of idle time and resets the timer. So if it's not possible to measure idle time on wayland (or really hard to do), I think it could be fixed by having that plugin return an error (like -1 or so) instead of 0, and then have RSIBreak use it's own timer and listen to the resumingFromIdle signal perhaps to reset? (I haven't checked if this would work). Just wanted to add to add to this bug report that's it's not actually an RSIBreak problem, rather a KIdleTime or KWayland problem. A possibly relevant merge request was started @ https://invent.kde.org/utilities/rsibreak/-/merge_requests/4 Adding that this also happens on Fedora 34 Would it be a good idea to create a temporary fix by adding `-platform xcb` to the desktop file, to force it to use x11 for the time being? *** Bug 474405 has been marked as a duplicate of this bug. *** *** Bug 453372 has been marked as a duplicate of this bug. *** *** Bug 479774 has been marked as a duplicate of this bug. *** version 0.12.15
When the break event occur, the timer ("for a duration of") does not decrease for more than 1 second.
I have 40 seconds short break. When the timer for break event kicks in and window appears, there's constantly either "please relax for 40 seconds" or "please relax for 39 seconds" message, switching between 40 and 39 seconds. It never decreases to 38 seconds or more. After 39 seconds, 40 seconds again.
The window disappears after 5-10 seconds.
Could it be a Wayland-related issue and the application fails to receive keyboard/mouse activity data? I tried to put my mouse cursor inside the window, but that didn't change anything.
STEPS TO REPRODUCE
1. Wait until break event occur and new window appears
2. Do not touch the keyboard or mouse
OBSERVED RESULT
The timer on break event beginning never decreases past 1 second
EXPECTED RESULT
Break event starts
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 39
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.6.9-200.fc39.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 13th Gen Intel® Core™ i5-1340P
Memory: 30,9 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: Intel(R) Client Systems
Product Name: NUC13ANKi5
System Version: N11211-203
It's a shame this hasn't been fixed for the Plasma 6 release because this is a dealbreaker for me. I'll have to keep using X11 until this is fixed. *** Bug 484145 has been marked as a duplicate of this bug. *** *** Bug 484925 has been marked as a duplicate of this bug. *** *** Bug 491943 has been marked as a duplicate of this bug. *** *** Bug 508542 has been marked as a duplicate of this bug. *** |