Synergy-core: Slowly moving the cursor has no effect on high DPI clients

[sleepyspider1]

Server: Windows 10 laptop
Client: Windows 10 desktop
version 1.7.5

When I move the cursor onto the client machine, if I move the cursor really slowly to the left or up it works fine. If I move the cursor really slowly to the right or down, the cursor does not move. I have to flick the mouse to get the cursor to move.

It looks like the cursor won't move unless the velocity is above some threshold.

This causes issues when I'm trying to select a tab in chrome, among other frustrations.

[AMagill]

I have the same problem, and it's very annoying. My Windows 10 server has a pair of 4K screens scaled to 150%, and the client has a single 1080p screen scaled to 100%.

This appears to happen because DPI scaling is done by integer division. See MSWindowsScreen::onMouseMove and Server::onMouseMoveSecondary. If the DPI-scaled mouse movement in a single update is less than one pixel in the positive direction, it gets truncated away. A sub-pixel movement in the negative direction also gets truncated into a single pixel decrement. The server needs to accumulate these fractional movements across updates.

This looks to be an easy fix. If I can manage to get the synergys building on my machine, I'll see about making a pull request.

[the-wes]

seeing a lot of reports of this since 1.7.5. if they uninstall and move back to 1.7.4 (and disable DPI scaling on synergys.exe), it doesn't happen. confirmed new bug!

[AMagill]

That's because DPI scaling of mouse movement was only added in commit a09bfc5. Which is the right thing to do, but implementing it is a bit trickier than it appears at first glance. I've been using the fix I wrote (PR #5190) over the last eleven days and it's worked pretty well for me.

[XinyuHou]

Could someone test this nightly?
http://synergy-project.org/nightly?filter=pr5190-accumulate-fractional-moves-beta-f240faf

[mike-rsi]

@XinyuHou I was experiencing the problem described in this issue when using a Surface Pro 2 with Windows 8.1 as the server and a MacBook Pro with retina display and Mac OS X 10.9→10.11 as the client. I had previously tried version 1.7.5 and 1.7.6 with no luck. The nightly build you referenced in the comment above seems to have fixed the problem for me. Thank you!

[AMagill]

@mike-rsi @XinyuHou Unfortunately, that nightly is out of date and likely to have some glitches (like the cursor on the client machine running off to the top right corner on occasional connects- work around by restarting the server until it works). I asked for a new nightly of PR5190 six weeks ago and haven't seen any movement since.

[nlyan]

We'll aim to get this in to 1.8.x

[fuzzzerd]

I too have this issue with Windows 10 DPI Scaling on the server; I'd be happy to test out the fix when it makes it into the nightly builds. Is there somewhere I can monitor that is going into them? (The above linked nightly link appears broken)

[nlyan]

Thanks for the offer @fuzzzerd . We'll be sure the post here with a nightly when we work on this issue.

Nightly builds are currently deleted after 30 days. You can keep track of what goes in to them here on Github, because we build for all platforms on every commit

[apclapp]

I have just started using Synergy, and have noticed this behavior, but do not have any scaling set on windows 10. I am able to move the cursor in any direction, however there is notable 'drift' towards the top and left directions of the screen, which is most visible when I make small circles with my mouse (or keep my finger in place on my trackpad and rolling it in a circular motion without moving the actual position of my finger).

I have noticed that when moving the mouse in a slight diagonal line going up and to the right (perhaps a ~15degree slant), the cursor will move in a perfectly vertical line (and won't exhibit any right-movement). I find the same behavior horizontally if I use my finger to draw a line going down and left on my trackpad at the same angle, the cursor will move perfectly horizontally to the left, and will not move downwards.

Not sure if any of this helps debug or diagnose the issue. Is certainly annoying that the cursor moves faster/slower in different directions. I don't see this behavior on the server (macOS)

Server: MacOS Sierra 10.12
Client: Win10, up to date as of Sept 22, 2016. No DPI scaling. 1366 x 768

[nlyan]

@apclapp Did this start when you updated your server to Sierra?

[apclapp]

I can't say with any certainty; I bought synergy shortly after updating to Sierra, so I don't have any experience with it prior to that.

[nlyan]

Can anyone experiencing this issue please try 1.8.4 RC3?

http://symless.com/nightly?filter=synergy-v1.8.4-rc3

[lasmith05]

Hi @nlyan ,

I am experiencing this issue, and have installed 1.8.4-rc3. Unfortunately it did not fix my issue. My cursor on my windows machine as I use it slowly "drifts" toward the upper left. I do think that this issue began after I upgraded my OSX server to sierra.

[fuzzzerd]

FWIW, @nlyan using that build on both client and server seems to have broken things for me completely. Client shows as connected, but I cannot share mouse or keyboard at all. This was on an upgrade install from 1.8.3. I will try a clean install and see if that helps anything.

[cyber-decker]

Server: Windows 1 0
Client: Windows 7
Original Version: 1.8.3-stable-db9181b

Background:
I just ran into this issue this morning, totally out of the blue. It was working fine for me for the past couple of weeks and now all of a sudden I was having this issue. On further investigation I found that when moving my mouse very slowly on the remote machine either downwards or to the right, that it was not moving at all. I had to move it very quickly in those directions to get it to register. I have a Corsair precision gaming mouse, so I was able to change the DPI mode so that my mouse would move very slowly. When using this, I was not able to move my mouse down or to the right at all. Only up and left. The issue persisted even after restarts of the server, the client, and their respective machines.

Steps to Reproduce:
1) move mouse into client window
2) move mouse in client window very slowly down or very slowly to the right (optinally enable high-dpi mode on the mouse for slower mouse movement)

Resolution:
Upgraded the server to 1.8.4-rc3-fcd8153 (64 bit version) on my Windows 10 machine (the server). After doing this, there were no problems. Could not reproduce this issue after upgrading on this configuration.

[fuzzzerd]

I can confirm that this nightly build fixes this particular issue for me. It seems to have caused a new problem though. Reinstalling from scratch made no difference, the issue appears to be with different DPI scaling settings on a multi-monitor Server.

While running 1.8.4-rc-3 with this setup:

[Client @ 150% DPI Scaling] [Server Screen #2 @ 100% DPI scaling] [Server Screen #1 @ 125% DPI Scaling]

Synergy shows connected, but I cannot move the mouse from Server to Client. If I change the Server to use the same DPI settings across all screens it now works beautifully.

Using this configuration:

[Client @ 150% DPI Scaling] [Server Screen #2 @ 125% DPI scaling] [Server Screen #1 @ 125% DPI Scaling]

Causes 1.8.4-rc3 to work perfectly. This seems to be a regression from an earlier build, but my configuration has shifted so I cannot say for sure what version of Synergy I was using when this config was working.

[PutzWorks]

This is the same problem I'm having on OS-X Sierra as server. Apparently it sends mouse events much faster, so most of them are fractional, and since it's based on the middle of the screen, the Int32 rounding always rounds down (if it were based off (0,0) then everything would get clipped and there would be no motion if moving slowly).

Is there any way you could put in the fractional motion check into the OSXScreen.cpp and OSXScreen.h like you did for the windows server? Also, the mouse scrolling seems to be having the same increased fire rate with smaller values and is suffering from int rounding clipping off the motion.

Issue number 5648 is identical to this issue, but for Mac OSX Sierra as the server.

EDIT: I have also verified that this issue is present on any client attached to a Mac OSX Sierra server.

[XinyuHou]

Can someone test this nightly please?
http://symless.com/nightly?filter=issue5186-different-dpi-rc1-8d193c7

[XinyuHou]

Fixed in 1.8.4