Synergy-core: Screen edge scaling is not intuitive

[nbolton]

... uses largest of multiple monitor dimensions, instead of "nearest" monitor's dimensions.

Imported issue:

• Author: Brian Porter
• Date: 2013-10-31 20:10:28
• Legacy ID: 3814

Steps to reproduce

1. Configure a Synergy server with a single monitor and a client with multiple monitors each having different resolutions, or where the multiple monitors are offset from one another so the tops and bottoms don't "line up" perfectly.
2. _(Different resolutions or having the client's monitors offset is key to this issue!)_
3. _(Operating systems do not seem to matter in my tests, but my server is Win7 x64 and my client is OS X 10.8.5.)_
4. Configure the client's monitors so that the smaller of the two is in the middle, with the larger client monitor on one side and the server's monitor on the other.

5. Configure Synergy so that the virtual screen arrangement mirrors the physical arrangement described above. For example:

   Large client monitor <-> Small client monitor <-> Server monitor

6. In this configuration, switching the cursor between Synergy's screens will cause it to be positioned relative to the height of the client's larger outside monitor instead of relative to the client's smaller middle monitor.
7. This diagram will help illustrate the issue further.
   

   Expected

Given the above 3(+) monitor configuration; the cursor should be positioned on the destination monitor using the percentage scaled position of the cursor when leaving the originating machine, as compared to the dimension (width or height) of the exiting monitor.

Actual

The cursor is positioned on the destination monitor using the percentage-scaled position of the cursor when leaving the originating machine, as compared to the _combined maximum dimension (width or height) of all monitors_ on the client.

The effect of this bug looks a lot like setting fractional and expanded transition dimensions in your config. I realize the following config is invalid, but imagine the consequences of it:

section: links
    Client:
        right(0,100) = Server(40,90)
    Server:
        left(0,100) = Client(-40,110)  # Invalid, but use your imagination and remember values are in percentages.
end

Example

Given the above 3 monitor configuration:

• Cursor starts on the client.
• Cursor travels right off the edge of the machine and should transition to the server.
• The cursor exits the client 200px down on a 900px tall monitor (which should be 22.2%%) but distance down is actually calculated as 800px compared against the crude_max(900px, 1920px) that represents the combined client screen height and giving an actual (but wrong) 41.6%% down.
• It therefore enters the server 41.6%% down on 1080px tall monitor; 449px down instead of the expected 238px.

Versions and operating systems

• Server:
  
  
  
  • Windows 7 SP1 x64
  
  
  • Synergy 1.4.15
  
  
  • Monitors: 1@ 1920x1080
  
  
• Client:
  
  
  
  • Mac OS X 10.8.5
  
  
  • Synergy 1.4.15
  
  
  • Monitors: 1@ 1080x1920, 1@ 1440x900
  
  

(See the diagram linked above for physical monitor and Synergy 'screen' arrangement.)

Temporary workarounds

• Don't use more than 1 monitor per machine.
• Only use like-sized monitors on each machine, with perfectly aligned edges (parallel to Synergy transition direction).
• Position the monitors so the largest dimension is on the "transitioning edge" between screens. Synergy will perform the percentage scaling correctly (by accident) in this case.
• Alternatively, position multiple monitors on a single machine perpendicular to the transitioning direction to the next Synergy machine (in a "triangle" formation) to take advantage of the properties of this bug (See Additional comments below.)

• Live with the fact that you can only transition between Synergy "screens" using a tiny fraction of your monitor's actual width/height.

  Similar bugs

• This question seems to describe a similar issue from a different perspective and use case.

  Additional comments

The big thing here is how Synergy calculates the dimensions of each "screen" in the set of servers and clients. Based on current evidence, it appears that Synergy draws a single large rectangle around all of the monitors attached to a single system and uses that single width and height for everything.

To fix this bug, Synergy would have to have an awareness of the individual dimensions of each monitor, and their relative arrangement in order to coordinate that with transitioning edges defined in the Synergy server's configuration.

This could be complicated by having multiple screens arranged in a "triangle" instead of a line-- say two vertically stacked client monitors to the left of a single server monitor. In this arrangement, the expected behavior would be that transitioning from the top client monitor would map to the top 50%% of the server monitor, transitioning from the bottom client monitor would map to the bottom 50%% of the server monitor, and vice-versa for server-to-client. This currently seems to work "by accident" given how Synergy calculates total screen dimensions, and should not break when the bug described here is fixed (in my opinion). Again: Synergy should take into account the relative _positioning_ of individual monitors when calculating the total length of a transitioning edge and do the right thing in each case.

There seem to be APIs for obtaining multiple monitor configuration for at least Windows and OS X. Linux you're on your own.

[nbolton]

• Author: Brian Porter
• Date: 2013-11-11 15:30:32

Duplicates/related: #3817, #3637, #3638

[nbolton]

• Author: Brian Porter
• Date: 2014-05-27 21:51:32

New duplicate: #4065

[beporter]

Updating list of duplicates:

• Old SPIT 3637 :arrow_right: GitHub _Screen positioning_ #3567 (closed)
• Old SPIT 3638 :arrow_right: GitHub _Screen positioning_ #3568 (closed)
• Old SPIT 3817 :arrow_right: GitHub _Dual Screen Issue_ #3747 (closed)
• Old SPIT 4065 :arrow_right: GitHub _Mouse jumps to wrong position with different screen sizes_ #3995 (closed)
• Mouse scroll off-screen not detected #4204 (closed)
• Synergy switches to wrong position bwtween Windows and Mac #4223 (closed)
• Sticky screen edge on PC #4234 (closed)
• multiple monitor support #4292 (closed)
• Dual screen support #4335 (closed)
• Does not traverse to client on exceptionally wide screens #4366
• Recognize Existing Multi-Monitor Setup #4795 (closed)
• Server to Client Transitions on Multi-Monitor configuration #4838

[nbolton]

@beporter Thanks for hunting those down!

[Bradleycorn]

any progress on this issue?

[frebib]

I too would like to see some progress on this. It's a feature that without it makes Synergy almost useless to me

[stefanflegg]

I'd like to see this also. I'm struggling to use Synergy on two Surface tablets with different external monitors (4K and QHD) and different scaling factors due to the mouse entry and exit positions being vastly different across the various screens.

[sifex]

@nlyan 2 years to the day. Any update on General Multi-Monitor Support?

[beporter]

@sifex Ironically, that's just when Nick imported the issues into Github. I had posted the original report in the old "SPIT" tracker a year before _that_. :confused:

[nlyan]

@beporter Thanks for sticking with us Brian. This is on our horizon.

[beporter]

Hi @nlyan. I'm afraid that I didn't stick with you. I felt like I had no practical choice but to abandon Synergy and replace it with ShareMouse about 2 years ago, I think. I've become too dependent on the workflow Synergy provided, but I couldn't get my work done due to its unreliability. I've slowly been unsubscribing from these threads as they've gotten periodic attention.

Granted, ShareMouse sure isn't perfect either and actually even the customer support (in terms of bugs actually getting _fixed_) isn't that much better, but day-to-day I've had fewer issues with ShareMouse than Synergy and I'm still glad I paid to switch.

None of this is your fault of course, you're just inheriting about a decade of community angst. So sincerely: Best of luck to you, Andrew!

[akda5id]

This is absolutely brutal bug in my situation. I have this setup: 2560x1440 | 1920x1200 | 1200x1920 all in a horizontal line. When I leave the 1440 high monitor around the top edge, my cursor is off screen top of the 1200 high monitor, and I have to drag it away from the sticky edge. And any time I throw my mouse to the top of that monitor (e.g. to click the close box) I get lost in the sticky mess. Please fix!

[beporter]

Reposting my original diagram, since Dropbox is shutting down their public hosting and the original link is going to die.

👋 Good luck!

[KimSJ]

Surely what is really needed is an "advanced mode" where Synergy has a large virtual canvas, and machines are described as polygons on that canvas. This would allow arrangements such as
1 2a 3a 4
2b 2c 3b 3c
for example
Machines physical screens could then be scaled to fit the polygons. Obviously there's huge scope for messing up if you get the ratio wrong, for example, for the heights of 2a and 2b/c; that could leave you unable to access the top of 2b's real estate. Not sure how to handle that. Can Synergy know enough to stitch things correctly from a simple grid like the interactive config, but with physical screens?

[nlyan]

So version 2 is adding independent "screen" positioning, within the confines of the existing config mechanism. The problem here is Synergy treats all the monitors attached to any given machine as one bounded canvas. Synergy can't do what @beporter wants in the last section of his illustration because it handles to 2 left hand monitors as if they're one screen filling the the yellow area. There is currently no multi-monitor awareness in any real sense.

[ssendev]

If anyone is trying to configure a multi monitor setup that is currently unsupportet it might be possible to fake it with edges onto the same screen.

e.g.
server S with 2 screens and client C with 3 screens

physical layout:
+----+----+
| C1 | C3 |
+----+----+
| S2 | C2 |
+----+----+
| S1 |
+----+

configure the screens in the OSs like this

virtual layout of S
+----+
| S2 |
+----+
| S1 |
+----+

virtual layout of C
+----+
| C3 |
+----+
| C2 |
+----+
| C1 |
+----+



md5-ca4a939b10ca2474d2590cdeb3db001b



# synergy config
section: links
        C:
                down = S                              # edge C1->S2
                left(33.333333,66.666666) = S(0,50)   # edge C2->S2
                left(0,33.333333) = C(66.666666,100)  # edge C3->C1
                right(66.666666,100) = C(0,33.333333) # edge C1->C3
        S:
                up = C                                # edge S2->C1
                right(0,50) = C(33.333333,66.666666)  # edge S2->C2



md5-fbd36c775fde8cf7050ff372d107d56b



c:
  right(40,90) = s
s:
  left = c(40,90)

[beporter]

Negative. Given this:

+-----+
|     |        +-----------+
|     |+----+  |           |
|  A  || B  |  |    C      |
|     |+----+  |           |
|     |        +-----------+
+-----+

I want 100% of the right edge of B mapped to 100% of the left edge of C.

What Synergy actually does is map 100% of _A_ to 100% of C.

[ssendev]

yes by default. but with the config i posted this is the case. the exact numbers might differ in the ascii it would be 20,80. which means the edge you want to jump to begins at 20% from the top and ends 80% from the top

edit: looking at it again in the asci it probably would be 33.3 and 66.6

[KevinXuzio]

Is there a solution for this? Still having the issue