Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xprintidle does not work on wayland #7

Open
not-ivy opened this issue Dec 2, 2023 · 5 comments
Open

xprintidle does not work on wayland #7

not-ivy opened this issue Dec 2, 2023 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@not-ivy
Copy link
Contributor

not-ivy commented Dec 2, 2023

see title;

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

@lmaotrigine
Copy link
Member

this is documented.

unfortunately, I'm not aware of an alternative.

@5HT2 5HT2 added enhancement New feature or request help wanted Extra attention is needed labels Jan 23, 2024
@5HT2
Copy link
Member

5HT2 commented Jan 23, 2024

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
Copy link
Member

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
Copy link
Member

5HT2 commented Mar 12, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants