Smartpause: add support for ext-idle-notify-v1 using pywayland

[deltragon]

Fixes #391.

This is an alternative to #553. Instead of relying on swayidle, which appears to have issues both on KDE as well as within Flatpaks, this PR uses pywayland to use the ext-idle-notify-v1 wayland protocol directly.

Tested on KDE Plasma 6.0 Wayland.
This still needs to be tested on compositors that do not implement the ext-idle-notify-v1 protocol. According to this, this would be Weston, Mir or GameScope. (Gnome still has its own solution.) The plugin will not work correctly on these compositors, but we should probably give a better error.

[deltragon]

I've tested this on the bigger desktops, no issues.
I did manage to test this on Weston - smartpause simply silently doesn't work, as without this change.

This is ready to merge.

[deltragon]

(Note that I had this previously marked as waiting on #561 - I since managed to work around that.)

[archisman-panigrahi]

Is there any dependency I need to install to test this? Also, will this still work on xorg (with xprintidle) after merging this?

[deltragon]

@archisman-panigrahi Yes, xprintidle will still work - this is only used on wayland (not gnome and not sway, since they have their own implementation).
Regarding dependencies - this does need pywayland, which I did add to the setup.py. However, it seems that pywayland is not packaged for debian, so I cannot simply add it to debian/control...
What is the process for requesting a package from debian? Or would we need to add it to our ppa?

[archisman-panigrahi]

What is the process for requesting a package from debian? Or would we need to add it to our ppa?

To request a package to Debian, one needs to file a bug report in the wnpp list https://www.debian.org/devel/wnpp/. Hopefully someone will package it, but it may take a while. Sending them a packaged version helps to speed up the process. I will try that. However, I am not very familiar with the process of official debian submission.

However, I can add it to the PPA. Most packages in pypi can be easily debianized.

[archisman-panigrahi]

Here is the debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076337

Now I need to figure out how to package it

[archisman-panigrahi]

I stabilized the builds of python3-pywayland (I have not tested them, though). They are hosted in the safeeyes daily builds ppa https://code.launchpad.net/~safeeyes-team/+archive/ubuntu/safeeyes-daily

The .deb packages can be directly downloaded from here https://code.launchpad.net/~safeeyes-team/+archive/ubuntu/safeeyes-daily

[archisman-panigrahi]

Are #561 and #576 independent of each other? I will be happy to test this in Ubuntu with my experimental pywayland package (which itself is untested), but I want to merge this only after pywayland is in debian, which may take a few months.

[deltragon]

@archisman-panigrahi Yes, this is independent of #561 (and vice versa).
In theory, we can make pywayland not a hard dependency on wayland, and fall back on xprintidle if it exists. That would make it work on environments where it is available already (eg. on Arch, and for people using the PPA), and keep everything the same everywhere else.

[Levi-Lesches]

Hi, I have a question about using this protocol on my own project. I tested on a few devices, and ext-idle-notify is not present on all Wayland devices. Notably, it was present on KDE + Wayland, but not on Gnome + Wayland. Further investigation revealed that the protocol is still in the "staging" phase, which is basically the pre-release phase. I am using a similar approach using libxcb on X11 and ext-idle-notify on Wayland, but I'm not sure what to do about these devices that use Wayland but not the protocol.

Have you guys run into such issues? And if so, do you have any workarounds you'd recommend? The only solution I can think of now is to wait for the protocol to be implemented on those devices.

[deltragon]

@Levi-Lesches You're right that ext-idle-notify is not implemented on GNOME+Wayland.
For that configuration, we're using a Mutter-specific dbus call:

SafeEyes/safeeyes/plugins/smartpause/plugin.py

Lines 91 to 110 in 003812c

	def __gnome_wayland_idle_time():
	"""
	Determine system idle time in seconds, specifically for gnome with wayland.
	If there's a failure, return 0.
	https://unix.stackexchange.com/a/492328/222290
	"""
	try:
	output = subprocess.check_output([
	'dbus-send',
	'--print-reply',
	'--dest=org.gnome.Mutter.IdleMonitor',
	'/org/gnome/Mutter/IdleMonitor/Core',
	'org.gnome.Mutter.IdleMonitor.GetIdletime'
	])
	return int(re.search(rb'\d+$', output).group(0)) / 1000
	except BaseException as e:
	logging.warning("Failed to get system idle time for gnome/wayland.")
	logging.warning(str(e))
	return 0

For other compositors such as Weston, Mir or Gamescope that implement Wayland but not ext-idle-notify, we're also out of luck.

[Levi-Lesches]

Ok, good to know it's not just me. I'm going to leave my implementation as-is and call it "future proof", since as time goes on, more Wayland setups will hopefully support it

[deltragon]

I think this is ready to be merged.
We have pywayland packaged in the PPA, and it is packaged on ArchLinux, Fedora and OpenSUSE Tumbleweed, as well as within the Flatpak.
pywayland is currently not in Debian Stable nor in a released Ubuntu version, but is on track to be with Debian Trixie (mid-2025) and Ubuntu 25.04, so in half a year approximately.
However, that said - this is not really a problem. The changes in this PR apply only to Wayland (except GNOME and wlroots), where smartpause currently is broken anyways - for all other environments (X11, GNOME, wlroots), this PR has no effect.
So this is an improvement for eg. KDE Wayland on Fedora, while eg. KDE Wayland on Kubuntu is currently broken, and will continue to stay broken until 25.04 is released.

[archisman-panigrahi]

@deltragon I am sorry about my complete silence. I have been very busy due to my PhD (I did not anticipate I would be so busy). However, I have a break from the coming weekend until mid-January, and I intend to test and merge all the PRs during this timeframe.

[deltragon]

@archisman-panigrahi No problem, I have also not been as active recently.
I have put together a discussion where I detailed my current plans for a new release: #671, containing this change and the GTK4 changes.