Idle detection is unreliable on GNOME

[salim-b]

In the new Furtherance based on Iced (v24.10.3), the idle detection on GNOME only works as supposed when Furtherance's window is visible, i.e. not minimized, fully hidden behind other windows, or moved to a workspace other than the currently active one.

I tested with Bluefin (bluefin-dx:gts which is currently on GNOME 45.6) and Ubuntu 22.04 (GNOME 42.9), using the Flatpak.

The old Furtherance built on libadwaita didn't have this deficiency, i.e. idle detection under GNOME reliably worked regardless of the window state.

[rickykresslein]

I've narrowed this down to a Linux issue. It does not affect Mac or Windows. I'm not sure yet if it is a "feature" in Linux, where it is being shut down when it goes to the background, or if it is a bug in Iced, or something else completely. Looking into it. Thanks for the report.

[rickykresslein]

Unfortunately, I don't think I will be able to fix this. I suspect it is something in Wayland. I need to try it on X11 to confirm. I'll keep trying though.

[salim-b]

Thanks for the update and your efforts! I'd like to help debug this but I lack the knowledge to be of much help here... please let me know if I can do anything!

---

I guess if this can't be fixed anytime soon, I'll revert to the old libadwaita-based Furtherance.

According to the official Flatpak docs, I have to find the Flathub commit hash belonging to the desired Furtherance version. Of the old Furtherance app identifier com.lakoliu.Furtherance, not io.unobserved.furtherance, I think.

Meaning:

❯ flatpak remote-info --log flathub com.lakoliu.Furtherance
                ID: com.lakoliu.Furtherance
               Ref: app/com.lakoliu.Furtherance/x86_64/stable
              Arch: x86_64
            Branch: stable
        Collection: org.flathub.Stable
          Download: 1.7 MB
         Installed: 4.6 MB
           Runtime: org.gnome.Platform/x86_64/46
               Sdk: org.gnome.Sdk/x86_64/46

            Commit: 273851f9d3efe8b56e83e08746f36a3c98b9066851793b90a8f9b09b8ecb5cf7
            Parent: b0667d0b90a9b41f36ef88d19f2fd147a41e3b7e9cad8aecbb0367447a440fde
       End-of-life: Application has been renamed to io.unobserved.furtherance
End-of-life-rebase: app/io.unobserved.furtherance/x86_64/stable
           Subject: Update screenshot links (f2226f7a)
              Date: 2024-10-03 11:52:05 +0000
           History: 

            Commit: b0667d0b90a9b41f36ef88d19f2fd147a41e3b7e9cad8aecbb0367447a440fde
           Subject: Update Furtherance runtime to 46 (a2aef2bf)
              Date: 2024-07-01 09:09:14 +0000

            Commit: 586d12aabf6b160b0f5223cc7fd0627f36517672dca04091e6a88bb4873f6090
           Subject: Release Furtherance 1.8.3 (1781b643)
              Date: 2024-02-05 14:40:35 +0000

            Commit: 9edb7fc7f22e894d903ce8340acca301198c655d5d0504d913bd3603cc37ca57
           Subject: Release Furtherance 1.8.2 (75770f3e)
              Date: 2023-10-16 06:54:50 +0000

            Commit: 13b323534770e6720c8b03552b27ba148a717009fbca0612320942b1a62d37c8
           Subject: Release Furtherance 1.8.1 (230b3793)
              Date: 2023-06-16 10:26:00 +0000

            Commit: c7b7a389a46ef88fac1ca76f6fd7d88aff307be33ea35ceda126b52369d14546
           Subject: Release Furtherance 1.8.0 (38ebb688)
              Date: 2023-06-05 12:07:04 +0000

So the above tells me 273851f9d3efe8b56e83e08746f36a3c98b9066851793b90a8f9b09b8ecb5cf7 is the latest commit of com.lakoliu.Furtherance. Should I use this (i.e. is this still the old app) or should I use the one before (b0667d0b90a9b41f36ef88d19f2fd147a41e3b7e9cad8aecbb0367447a440fde)?

And if I downgrade, would I have to first export current Furtherance's DB and re-import it in the old Furtherance (because of DB schema changes)?

[rickykresslein]

Sorry, I just don't have the time or capacity to support reverting to the old version. However, the good news is I created a work around that solves this for now. On GNOME, Furtherance will now launch using XWayland, which isn't great but doesn't seem to cause any issues and will work until I can get this fixed another way.

The issue seems to be that Wayland automatically stops drawing and updated all apps that are not visible, which is cool in theory for performance/efficiency but sucks for any app that needs to keep running. Obviously GTK4 apps have somehow gotten around this, so I'll need to look into how they do that.

I hope this will be fixed upstream in either winit or iced, but until then I will keep trying to come up with a better solution.

I'll put out a new release with this fix soon, hopefully later today.

I really appreciate all of the work you've done over the last couple of weeks to improve Furtherance, @salim-b. Hopefully this is a satisfying solution for the time being.

[salim-b]

Thank you for providing technical insight and trying to come up with this XWayland workaround!

I just updated to Furtherance v24.10.4, but unfortunately it doesn't work at all for me (neither on Bluefin nor on Ubuntu 22.04), Furtherance just crashes on start:

RUST_BACKTRACE=full /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=furtherance --file-forwarding io.unobserved.furtherance
thread 'main' panicked at /run/build/furtherance/vendor/iced_winit/src/program.rs:192:10:
Create event loop: Os(OsError { line: 760, file: "/run/build/furtherance/vendor/winit/src/platform_impl/linux/mod.rs", error: Misc("neither WAYLAND_DISPLAY nor WAYLAND_SOCKET nor DISPLAY is set.") })
stack backtrace:
   0:     0x60ba39b27049 - <unknown>
   1:     0x60ba39243b0b - <unknown>
   2:     0x60ba39af0512 - <unknown>
   3:     0x60ba39b2bbe8 - <unknown>
   4:     0x60ba39b2ca92 - <unknown>
   5:     0x60ba39b2c585 - <unknown>
   6:     0x60ba39b2c4e9 - <unknown>
   7:     0x60ba39b2c4d4 - <unknown>
   8:     0x60ba390f6802 - <unknown>
   9:     0x60ba390f6c25 - <unknown>
  10:     0x60ba394cfb0a - <unknown>
  11:     0x60ba3916bc03 - <unknown>
  12:     0x60ba394cbd35 - <unknown>
  13:     0x7d8dc64f5188 - <unknown>
  14:     0x7d8dc64f524b - __libc_start_main
  15:     0x60ba391525a5 - <unknown>
  16:                0x0 - <unknown>

Let me know if you want me to open a separate issue for this :)

[rickykresslein]

That's annoying. I like Flatpak as a user, but as a developer it can be a nightmare. I'm going to revert the changes for now. Unfortunately, that means idle detection won't work on Wayland while the app is in the background unless you can force it to run in XWayland yourself by setting the environment variables GDK_BACKEND=x11 and WAYLAND_DISPLAY=. It seems that not having WAYLAND_DISPLAY set doesn't work in the Flatpak for some reason.

I will continue trying to work on another solution.

[salim-b]

I can only imagine how Flatpak can make development frustrating, especially in conjunction with new or not yet sufficiently standardized protocols and technologies. 🙈
Thanks for keeping trying!

IIUC, you're currently querying org.gnome.Mutter.IdleMonitor.GetIdletime over DBus to get the idle time under Linux (Wayland).

Now there seems to exist a dedicated ext_idle_notify_v1 Wayland protocol providing the two interfaces ext_idle_notifier_v1 and ext_idle_notification_v1.

I don't know the implications of GNOME's Mutter compositor not (yet?) implementing this Wayland protocol.

The wayrs_protocols Rust crate implements the ext_idle_notify_v1 protocol in Rust. A seemingly simple usage example is the wayidle CLI.

Maybe you could build upon wayrs_protocols::ext_idle_notify_v1?

[rickykresslein]

Yeah, I've already started working on an implementation using wayrs_protocols::ext_idle_notify_v1 but haven't yet found a way to do it that works well and doesn't impact performance significantly. I just need to dedicate more time to it, and this bug will make me do that. I'm quite busy with work at the moment, but in the next week or so hopefully I can dedicate some time to this.

[salim-b]

Great to hear! And please don't feel pressured by me and this bug. I totally understand that there are other duties. Good things take time. 😊

[salim-b]

Small addendum: This issue in another project mentions the org.freedesktop.portal.Inhibit XDG Desktop Portal spec as a means to monitor idle time. While the issue says it only relies on the "screensaver state", I think v3 of the spec now includes session-state info besides screensaver-active in the org.freedesktop.portal.Inhibit::StateChanged signal. So if I'm not mistaken, org.freedesktop.portal.Inhibit.CreateMonitor should allow to monitor system idle state (without inhibiting anything of course and just answering with QueryEndResponse on signal reception).