[GH-ISSUE #181] idle inhibit on unfocused computers #80

New issue

Open

opened 2026-05-05 22:08:24 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 22:08:24 -06:00

Owner

Originally created by @sodiboo on GitHub (Aug 26, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/181

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.

Originally created by @sodiboo on GitHub (Aug 26, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/181 I've just come across lan-mouse, and to use it [i had to implement some stuff in my compositor](https://github.com/YaLTeR/niri/pull/630) ([lol](https://github.com/sodiboo/nix-config/compare/24a484d541cf95142cbffb7c5cb0b75689180524..1b751b2b50292cc0f2bd19bbfdae120a4097d845)). 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.

gitea-mirror commented

2026-05-05 22:08:25 -06:00

Author

Owner

@feschber commented on GitHub (Aug 26, 2024):

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.

@feschber commented on GitHub (Aug 26, 2024): `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](https://wayland.app/protocols/ext-idle-notify-v1) on device **A** to check if it is idle and idle inhibition on device **B**. But yeah this is not implemented.

gitea-mirror commented

2026-05-05 22:08:26 -06:00

Author

Owner

@sodiboo commented on GitHub (Aug 26, 2024):

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.

@sodiboo commented on GitHub (Aug 26, 2024): > 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.

gitea-mirror commented

2026-05-05 22:08:27 -06:00

Author

Owner

@poddmo commented on GitHub (Aug 27, 2024):

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

@poddmo commented on GitHub (Aug 27, 2024): 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

gitea-mirror commented

2026-05-05 22:08:28 -06:00

Author

Owner

@kevinclevenger commented on GitHub (Oct 14, 2024):

To add to this a bit ... I have [B] [A] [C], if swaylock is triggered by normal idle timeout on [B] while I'm working on [A] and I accidentally mouse too far left (into [B]) the mouse cursor is captured by [B] until I unlock [B]. Which of course can become annoying pretty quickly. This issue would fix that, or maybe a (configurable) dead-zone buffer of 200-300px between screens would also help. (swayfx/niri).

Loving lan-mouse otherwise, thank you so much for it.

@kevinclevenger commented on GitHub (Oct 14, 2024): To add to this a bit ... I have [B] [A] [C], if swaylock is triggered by normal idle timeout on [B] while I'm working on [A] and I accidentally mouse too far left (into [B]) the mouse cursor is captured by [B] until I unlock [B]. Which of course can become annoying pretty quickly. This issue would fix that, or maybe a (configurable) dead-zone buffer of 200-300px between screens would also help. (swayfx/niri). Loving lan-mouse otherwise, thank you so much for it.