MacOS Multimonitor support

[Jacoby6000]

I'm pretty new to rust, so don't be afraid to tell me anything I did horribly wrong 😅

This seems to fix multi-monitors on macos and hasn't had any issues from what I can tell.

The basic process is:

• Get the current monitor that the mouse is on
• Check what the new position would be if we just added dx and dy
• Check if there is a display at that new position
  • If there is a different display there, clamp using its bounds
  • If there is not a different display there, clamp using the current monitor's bounds

Resolves #83

[feschber]

Regardless of the above comment: It does look like a good fix to me and the optimization mentioned could be made in a separate PR.

Unfortunately I have no way of testing multiple displays on MacOS, so I will have to trust you on this ;)

(maybe @jpeeler can confirm?)

[nbolton]

I'm curious, does this allow for the complex geometry caused by multiple screens or does it have the "one big rectangular screen" problem that Synergy has?

e.g.

[feschber]

@nbolton No, this is only about being able to move the cursor onto different screens when controlled remotely. I was lazy there and clamped it to the boundaries of the primary display instead of any display.

The "activation" barrier is a big rectangle as well (as of right now):
https://github.com/feschber/lan-mouse/pull/131/files

[Jacoby6000]

I'm curious, does this allow for the complex geometry caused by multiple screens or does it have the "one big rectangular screen" problem that Synergy has?

Assuming you're talking about the issue with synergy where your mouse would get stuck off screen up until it hit the coordinates of the largest x/y bound of the given side: this solution does not have that issue. It uses the bounds of the display that the mouse is currently on to avoid that issue. When the mouse goes off screen, it checks if it would be on a new monitor. If it would, it does not clamp the position. Otherwise it clamps to the current display bounds.

[Jacoby6000]

Regardless of the above comment: It does look like a good fix to me and the optimization mentioned could be made in a separate PR.

Unfortunately I have no way of testing multiple displays on MacOS, so I will have to trust you on this ;)

(maybe @jpeeler can confirm?)

I think your above comment about the optimization got lost, but I think I have one in mind.

I can make a single call to get every display that the mouse might be on by checking with a rect of size dx, dy. From there I can also do smarter clamping by pulling the mouse back in to the nearest edge rather than simply camping. However by the time I'm done doing all that I'm not sure it would perform better than the current solution 🤔 I'm not sure what the overhead of calling CGGetDisplaysWithRect is

[feschber]

I'm curious, does this allow for the complex geometry caused by multiple screens or does it have the "one big rectangular screen" problem that Synergy has?

Assuming you're talking about the issue with synergy where your mouse would get stuck off screen up until it hit the coordinates of the largest x/y bound of the given side: this solution does not have that issue. It uses the bounds of the display that the mouse is currently on to avoid that issue. When the mouse goes off screen, it checks if it would be on a new monitor. If it would, it does not clamp the position. Otherwise it clamps to the current display bounds.

Ah yes, you're right. There is two problems to solve here, really:

• on the emulation side, we need to make sure the cursor can not leave any of the display bounds (which is what this PR fixes)
• on the capture side, we need to make sure that all of the edges trigger an Enter event (which I was thinking about, since it currently is not the case)

[feschber]

I'm not sure what the overhead of calling CGGetDisplaysWithRect is

This is exactly the problem, I have with the solution. We dont know how expensive this call really is. Therefore, I'd prefer to only call this function whenever we need to (= when some display is connected / rearranged).

I would merge this now, if you're fine with that and we can do these things in a separate PR

[nbolton]

The "activation" barrier is a big rectangle as well (as of right now):
https://github.com/feschber/lan-mouse/pull/131/files

[Off-topic] Looking forward to seeing how you solve that one. I haven't attempted it yet.

[Jacoby6000]

I'm not sure what the overhead of calling CGGetDisplaysWithRect is

This is exactly the problem, I have with the solution. We dont know how expensive this call really is. Therefore, I'd prefer to only call this function whenever we need to (= when some display is connected / rearranged).

I would merge this now, if you're fine with that and we can do these things in a separate PR

Sounds good to me. I'll look in to putting in the more optimized fix in the coming days.

[feschber]

Thanks again for the contribution!

[feschber]

The "activation" barrier is a big rectangle as well (as of right now):
https://github.com/feschber/lan-mouse/pull/131/files

[Off-topic] Looking forward to seeing how you solve that one. I haven't attempted it yet.

It is going to be hard for me to test this without a Mac so might take a while ...

In Linux it all works very differently but I tried to implement this in Windows before.
Ran into some issues with Windows teleporting the cursor around so I gave up on it at the time.

[jpeeler]

Regardless of the above comment: It does look like a good fix to me and the optimization mentioned could be made in a separate PR.

Unfortunately I have no way of testing multiple displays on MacOS, so I will have to trust you on this ;)

(maybe @jpeeler can confirm?)

It's been a while since I last tested, so I don't have a good comparison point. But with latest code it seems to work as expected with multi-monitors on MacOS.

---

I know this is the not the right place to have this conversation, but would a request for supporting smithay based compositors be considered? (I've migrated from hyprland to niri.)

[feschber]

Regardless of the above comment: It does look like a good fix to me and the optimization mentioned could be made in a separate PR.
Unfortunately I have no way of testing multiple displays on MacOS, so I will have to trust you on this ;)
(maybe @jpeeler can confirm?)

It's been a while since I last tested, so I don't have a good comparison point. But with latest code it seems to work as expected with multi-monitors on MacOS.

thanks for confirming!

I know this is the not the right place to have this conversation, but would a request for supporting smithay based compositors be considered? (I've migrated from hyprland to niri.)

This is really more of a smithay supporting lan-mouse kind of thing instead of lan-mouse supporting smithay. You would need either libei support through input-capture portal or support for the wlr-virtual keyboard / pointer protocols