idle inhibit on unfocused computers

[sodiboo]

I've just come across lan-mouse, and to use it i had to implement some stuff in my compositor (lol). There are a couple annoyances that i've experienced which i think mostly boil down to limitations in being a wayland client (most notably, i would love if keyboard focus would stay on the previous computer even if my mouse is on another, particularly because it fucks with my window rules and causes the focused window to flicker its transparency). One thing that i'm fairly certain isn't a limitation, and feels more like a bug is this:

When i am moving my mouse and actively using one computer, the other computer is counted as "idle" and my swayidle events are triggered. Eventually this causes my laptop to spawn swaylock, which is annoying. It would be nice if lan-mouse would detect the idleness of the "active" computer (e.g. if i'm actually idle, then allow all idle timers to increment) and properly activate an idle inhibitor on the other computers accordingly.

I'm not sure how well/easily this concept translates to non-Wayland platforms, but personally i only care to use lan-mouse on Wayland, so it really doesn't matter to me.

[feschber]

lan-mouse does currently not do any idle inhibition.
When controlling device B from A, device A should not be able to idle since there is pointer motion captured on A, however if device A is used while device B is "connected", there is nothing preventing device B from idling.

Is that what you mean? In that case it would probably require something similar to idle notify on device A to check if it is idle and idle inhibition on device B.

But yeah this is not implemented.

[sodiboo]

however if device A is used while device B is "connected", there is nothing preventing device B from idling.

Is that what you mean?

Yes. This is the same physical topology of my setup where I would not expect device B to be idle.

[poddmo]

Ideally configurable per client device:

however if device A is used while device B is "connected", there is nothing preventing device B from idling.
Is that what you mean?

Yes. This is the same physical topology of my setup where I would not expect device B to be idle.

but device C is only accessed rarely and can idle/lock the screen