Jump to content

Hello! ūüĎč

These forums are now archived (read only).

Join us on Discord.

No more masters (feature request)

Etienne Faure

Recommended Posts

Etienne Faure


Feature request: being able to use computer A's mouse with computer B's keyboard on computer C.

In other words, no client becomes master, but they all share the same focus.

A feature I was hopping to get since the announcement of Synergy 2.

Usecase scenario: at work I have a mac, windows desktop and I bring with me a thinkpad. I want to control the mac with a physical mouse always connected to the desktop, using the thinkpad's keyboard. In this configuration, I would just arrive with my thinkpad, sit down, and everything would work.

  • Like 1
Link to comment
Share on other sites

I think I am having similar issues -- though appologies if it is a diferent issue.

I use a mouse and keyboard on a windows desktop, and have a portable mac sometimes connected and have them connected through Synergy 2.

Occasionally I need to use the mac trackpad to do some of the things that require multi finger gestures, this is totally fine for me as the trackpad is only 20cm from the mouse, but when I do it, synergy falls over, drops all control of the mac, and required me to open the synergy app (in windows), and click on things at random until it starts again, which can take several minutes.

back ot the example above -- Ideally it would retain focus on whichever window on whichever computer was supposed to be in focus and retain control regardless of which input devices were in use. In perticular, the holy grail here would be the ability (in for example photoshop) to be able to hold down shift on computer B, and click a mouse button on computer A, and that be recieved as a "shift-click" on computer C.

Link to comment
Share on other sites

  • 2 weeks later...
Rajveer Aujla

Yes! This is exactly the workflow that I want. I often push my desktop keyboard back and put my Macbook in front of my monitor, then type with my Macbook's keyboard but use my desktop's mouse. Every now and then I'll want to type on my desktop and with Synergy 1 I had to do this on it's actual keyboard.


With Synergy 2.0.12-Beta I get some interesting behaviour. As soon as I type or mouse click on either my Macbook or the desktop, that PC takes control (and it's mouse becomes the focus). This allows me to move the mouse/trackpad to the other computer and start typing, but it would be better if focus was derived from where the shared mouse pointer was last and then allow all keyboard to type to that computer. As it is right now, I can't use my setup as I used to with Synergy 1 as whenever I type on my Macbook I then have to reactivate the desktop mouse by mouse clicking and then moving it back to the Macbook, however the mouse-focus solution would fix my problem AND would give the behaviour we are looking for (all clients can contribute with their keyboard and they don't change mouse focus).

Link to comment
Share on other sites

i would guess this requires a redesign of the master/server App to split it in two Parts, so overall it works like this:

Input App: collects all Input Data* and sends it to the Master (runs on each client)
Master App: makes sense of all the Input data it receives from diffrent Sources (runs on one client only, preferably the most reliable; dynamic change like the current server app does makes much sense here in case the current master goes down)
Output App: Gets the Input Data from the Master App for its client (runs on each client) - this is basically the same as the current synergyc app



*maybe exclude specific Input Sources which make only sense locally, like for example touch displays

i think the most sensible way to progressively add such a thing is to first implement external/networt input sources to the current Server App, and also copy and modify it into an Input Grabber App which just sends the input it captured to the current master instead of deciding where it shall go and iterate from there.



i guess i played a bit Captain Obvious here - just see it as my +1 to this idea..

Link to comment
Share on other sites

Etienne Faure


Your solution would work but would be dependent on the MasterApp: if the device running it goes offline (or has wifi issues), so does the whole Synergy ring. And I wouldn't bet on reliability with a dynamic MasterApp change system (like ending up with two conflicting MasterApp).

I know in Synergy the original terminology was server and client, as a setup was that rigid once done. Now it's more of all clients interconnected with switchable master and slaves.
The current system has one master and N slaves. As soon as a physical input is touched, it becomes master. What could possibly be done is to have only masters: as soon as the connection is made, each client becomes master of the current position (initial input) and any update of one (mouse movement, client change) is broadcasted to all. A similar kind of message as the master->slave one but marked as master->master.
It could even be simplified as: hardware input -> broadcast to all masters -> { if master == current target -> software input } ; and thus there would be no need for the master->slave message.

Whichever solution is chosen, and even in its current state, a keyboard shortcuts like "toggle synergy on/off" (force physical control) would be helpful. I ended up in a meeting with my laptop connected to wifi and blindly controlling another computer at my desk, ugh.

Link to comment
Share on other sites

the problem i see with this system is that you have to synchronize the status between all instances, because if it gets out of sync you get weird results like simultaneous input on multiple devices or no device reacts to input because all of them think they dont have it.. solvable but not trivial imo.

also i see no way to iterate to this from the current system - i think its basically a re-write from ground up.. thats why i suggested a single "Master" Process to simplyfy things.. the dynamic switching of said master app is the next iteration, and possible conflicts of which is the current master (and wheter one needs to start up) are easier to solve than a pure p2p system for such a thing:

=> The Master App announces itself to all In/Out Apps and the time it was started on the Network (not just on startup but regulary)
=> if it receives another such announcement it compares the start time:
 -> when the current instance is newer it stays (and possibly sends out another announcement earlier to clean up faster because it can assume there is another instance somewhere out there)
 -> when the current instance is older (or exactly the same age) it exits (and possibly signals to other currently connected in/out apps to switch the master)
=> The In/Out App Listens to aforementoined Announcements and uses the Adress of the newest Instance it receives an announcement for to connect
=> If the In App cannot reach the current Master when trying to send new Input Data it starts a new Instance of said Master App (which obviously does the aforementoined things to stop possibly running older instances)
=> The Out App will only listen for announcements when it cannt connect to a valid master (ofc it first attempts all known/possible ones)

of course this relies that the times of all computers are in sync, but when using the default settings this should be true, at least for Linux and Mac (Windows might be an exeption - not sure if they still track time internally in Local time instead of UTC/Unix Time or similiar which might cause confusion)

Link to comment
Share on other sites

Etienne Faure
55 minutes ago, UniTrader said:

If the In App cannot reach the current Master when trying to send new Input Data it starts a new Instance of said Master App

That equates to a timeout, and I'm still not a fan of relying on timeouts for taking back control in case of one client's issue, but I have never seen the source code and I understand the need to not rewrite everything.
Still, let me describe a scenario that, even if not so often, can be a bit irritating as a user:
You have 3 clients, A, B and C. You are controlling A with B's keyboard and C's mouse. You are in the middle of typing something, like an email or some piece of code, and at that time, C happens to be the Master App.
C fails (brutal restart from Windows update, network failure, system drive crash, you name it), and at that point, what you thought was happening was between B's keyboard and A, but you are cut from typing and loose keystrokes. In this scenario I have in mind, B is a laptop, and there still is the touchpad in front of the user, but you then have to wait for a timeout to resume typing.
And this timeout *will* have to be in order of seconds, because you don't want a ping pong of Master App switch on non-perfect wi-fi either.
I can imagine more scenarios like this one that would make Synergy "feel" less reliable than it could: because let's face it, during this timeout wait, the user lost control of all his systems, regardless of the input.
As I said, I haven't seen the source code, it's just that how I imagine it (how I would have written it), the solution I proposed seemed more like code refactoring than a complete rewrite of internals.
The concept I was proposing is different, yes, very, but almost all the building blocks would be very much the same.
From what I have tested, the current state of Synergy 2 is, at best, as reliable as Synergy 1. It isn't perfect. The solution you propose adds a layer on top of that and can't, by definition, add to the existing reliability.
If I had more time, and given the opportunity, I would be happy to look into Synergy's source code for more insight, but I'm afraid neither are available.
Link to comment
Share on other sites

Etienne Faure
1 hour ago, UniTrader said:

the problem i see with this system is that you have to synchronize the status between all instances

That one should be easy enough: require all clients to be time-synced, timestamp all events and any client out-of-sync can implicitly invalidate itself.

Link to comment
Share on other sites

Etienne Faure

[I wanted to edit my previous post]

The issue you pointed out in my proposal can be resolved. For it to be even possible, I assume the only information in the event packet are the focused client 'X' and 'Y' position. Then add a couple integers for 'focusedClientId' and 'timestamp'. I doubt enriching it with this would degrade performance in a noticeable manner.

The issue I pointed out in your proposal has no other fix than to teach the user to cope with a known flaw.

Link to comment
Share on other sites

Etienne Faure

Nevermind, I found synergy-core's github. I'll have a go at forking it over the next week-ends I have free.

I won't try to force my point of view anymore and I'll let you know if I come up with something interesting.

I'm sorry if I have irritated you here.

Link to comment
Share on other sites

Rajveer Aujla

I too was thinking along the lines of "all messages from all clients are sent" and they all contribute, but whilst keeping Synergy 2's switchable master methodology. If we want to keep the master-client analogy and not broadcast to all clients, we could do:


- there is one shared mouse pointer

- master = computer with shared mouse pointer within it's bounds

- all clients send any input (mouse or keyboard) to this master (and keyboard input is only applied to the master as it has mouse pointer within it's bounds)

- this master decides whether it should pass on being the master to another client, and will do if it receives input that would take the shared mouse pointer out of it's bounds, at which point it nominates a new master


However, I think a simpler solution to get it working quicker with how Synergy 2 seems to work (any keyboard or mouse button makes the computer the master) would be to do the following:

- make mouse/trackpad movement also trigger becoming a master

- when a client becomes a master, make it remember the last shared mouse position and to keep it there (so then all clients should always know the shared mouse position for if they become master)


This solution however would cause 2 computers to constantly become masters (if the user is using a keyboard and mouse on different computers) but it may just work with less modification.

I don't really consider race conditions of multiple mouse/trackpads much of an issue as in real life it would be one device that is used at any one time (since it'd be one person).

Edited by Rajveer Aujla
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Create New...