upstream quirk to document: some media playing is treated as activity in Wayland

[wolftune]

Noting here in case there are any other solutions to explore and so the behavior is documented (perhaps should be noted in README?):

There's a problem with idle detection in Wayland such that, as an example, if I have a video open in mpv, it gets counted as activity and will not pause sane-break even if the video isn't playing (I think) and when the prompt is happening, it will block the full break until the force-break time comes.

See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/213 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/229 which were referenced at rcaelers/workrave#523 (comment) in terms of WorkRave having the same problem in working on Wayland

[AllanChain]

With c5549fe, a workaround is to pause when mpv is running. I'm going to test it for a few days before releasing. And yes, I should mention it in README.

[wolftune]

Pausing when mpv is simply open has issues as a workaround. I just tested and confirmed that mpv only gets counted as activity while playing, not just while open.

I would want to be able to have an mpv window open but paused and still have breaks show up and happen. I can do that now.

Perhaps there's a way to make sane-break pause only when mpv is playing but that sounds complex. And anyway, maybe I don't want it paused even then. Maybe it's good in a way to count media playing as activity and get the break prompt still, and then if it's documented at least people can know that to allow the break to happen, the user has to pause the media in addition to stopping any typing or cursor activity.

For me, I think that will work. I might not change anything in sane-break, I just need to change my own expectations and take breaks by pausing the media (and knowing that if I just walk away, the forced-break will still come eventually and the media will keep playing). I'm okay for now that I at least understand what does and doesn't happen here.

[jjramsey]

Perhaps there's a way to make sane-break pause only when mpv is playing

Offhand, I'm doubtful of that. One of Wayland's features is that Wayland apps have very little information about what other Wayland apps do, except via the limited information that the compositor lets them have.

I still think the best move is for the the developers who rely on the idle-notify protocol lean on its maintainer to fix it. I've probably done what I can as an end user to try to raise awareness of problems with the protocol, but I am just that, an end user, not a developer. Developers are probably more likely to get the ear of the maintainer.

[wolftune]

Well, IMO, what sane-break could do for this situation is to note it in the README so people simply know that mpv playing (and similar) will be seen as activity by sane-break. And perhaps include a quick link to the idle-notify issue tickets.

I agree that nothing in the actual code should be done ;)

[AllanChain]

If we really want to detect whether mpv is player, we can use D-Bus MPRIS to get media status, including player name, paused or playing, etc.

One possible (yet tricky) solution is to allow users to configure which players should be treated as:

1. always busy: the user wants to take breaks when watching video
2. pause breaks: the user does not want to take breaks when watching video
3. others: keep default behavior

Or, even more trickily, we can have a set of default rules to detect if the played media is video or audio.

I haven't explored Windows or macOS API yet, therefore the design can change.

Edit: For now, a note in README is enough, I think.

[jjramsey]

MPRIS sounds like an interesting workaround, but I can see a scenario where someone plays a video to have something "interesting" going on in the background while they do something that still involves typing and mouse movement. If the user has configured sane-break to pause breaks while watching that video, then they aren't getting the breaks that they should get.

Fundamentally, the problem is that there's no way to tell from the current idle-notify protocol whether a user is really physically active or if some Wayland app has instantiated an idle-inhibit object. As I indicated before, a complaint about that problem to the maintainer of the idle-notify protocol, @emersion, might have more weight if it comes from @AllanChain or @rcaelers rather than just me.