5HT2B / heartbeat-unix

The heartbeat client for Linux, macOS and Unix
ISC License
2 stars 1 forks source link

`xprintidle` does not work on wayland #7

Open not-ivy opened 10 months ago

not-ivy commented 10 months ago

see title;

xprintidle outputs screen saver not supported when run under wayland, breaking if expression

lmaotrigine commented 8 months ago

this is documented.

unfortunately, I'm not aware of an alternative.

5HT2 commented 8 months ago

Yeah this is something I'm not really sure of a proper way to do it on Wayland, there's no API for it.

Relevant links:

However, it is possible to implement DE-specific solutions, which I'd rather avoid given this repo is meant to be as abstracted as possible, but given the choice right now is X11 or macOS, it wouldn't really hurt to implement an option for Gnome / KDE APIs

For kwin (KDE) and Sway:

https://wayland.app/protocols/kde-idle

I don't reallllly see an easy way to access this on a CLI/shell, the easiest solution would to make heartbeat-unix a Rust program that can be called by whatever daemon is relevant.

For Mutter (Gnome):

It's not as straightforward documentation-wise but this also exists as an implementation in the compositor: https://github.com/GNOME/gnome-desktop/blob/8fb7ee85ace2823c32c59a0e6332c138ab5d83cc/libgnome-desktop/gnome-idle-monitor.c#L436-L459 https://github.com/GNOME/gnome-desktop/blob/8fb7ee85ace2823c32c59a0e6332c138ab5d83cc/libgnome-desktop/gnome-idle-monitor.h#L81

This stackoverflow answer gives an example of a way to access the org.gnome.Mutter.IdleMonitor API through dbus, but that answer assumes the user has a functional dbus daemon (which, to be fair, is a reasonable assumption on Gnome). https://askubuntu.com/a/1231995

Ozone

The Ozone project has had a low-level implementation of this since 2020, which I wasn't really aware of at the time of writing heartbeat-unix: https://bugs.chromium.org/p/chromium/issues/detail?id=1098201 It seems to provide a nice interface for org.gnome.Mutter.IdleMonitor, which is the quote unquote proper way to do this on Mutter.

Wayidle

And finally, I'd like to mention another potential contributing solution I found while researching this just now, this seems to be generic to Wayland compositors in general, and either calling this through the script as an alternative to xprintidle or implementing the same APIs in a Rust rewrite of this project would be probably the most ideal solution?

https://git.sr.ht/~whynothugo/wayidle

lmaotrigine commented 8 months ago

wayidle waits for a specified idle interval before returning. This complicates things for our purposes, see elaboration in #9.

https://discussion.fedoraproject.org/t/wayland-equivalent-of-xprintidle/64760

This, but calling libdbus directly, for common DEs with an environment variable override is what my WIP cross-platform Rust client does. I'm slightly on the fence about this approach though. I feel like it's better to wait until there's a good API for this; but I will probably reconsider if there's increasing demand for this.

If that solution is acceptable to OP, I can get started on getting a working prototype out that they can use in the meantime.

5HT2 commented 7 months ago

Hm. Yeah I'm not seeing a nice way to get it working without DE-specific tweaks, which is why I linked multiple potential solutions rather than a clear one, but it depends on whatever path we end up going with replacing the unix scripts or keeping them instead of as a tool that's part of the Rust impl.

lmaotrigine commented 1 month ago

I took a stab at this, and it turns out that having multiple code paths for different DEs really adds up. There are also assumptions to be made, or left as configuration (e.g. should we look at the first available seat? All seats?). Pulling in wayrs also adds more than 2MiB to binary size, and isn't exactly fast to compile because it uses proc macros to parse a Wayland protocol specification instead of just checking the generated bindings into crate releases. On environments where querying dbus is an option, I feel like this overhead isn't necessary. However, these can only be configured at compile-time, which would mean we would now require our users to have a Rust toolchain installed. I'm not sure how I feel about this.