Synergy

Google user: nick.bolton.uk

Are you saying that your configuration works fine before changing the screen
resolution?

Google user: hendersj

Hi, Nick - yes, things do work fine before the resolution change.

I think it's likely (but I haven't tested) that a similar problem exists with
displays set up one over the other - you probably would have the same issue moving
the top screen to the bottom as well. If I have some time this weekend I can try
that out and see if that also happens.

Google user: nick.bolton.uk

Maybe there's a new way of changing screen resolution that synergy doesn't
understand; could someone confirm that this does or does not happen on any other
platforms?

Google user: hendersj

Could be, Nick - the changes that I'm making are using the xrandr command (in a
script). It may be something Linux-specific.

New Accepted

?

Google user: BostonVaulter

I get a similar issue when using xrandr to set up an external monitor to the left of
my primary. When I move my mouse to the right side of the left monitor it jumps to my
other computer which is on the right of my primary monitor. It appears that synergy
doesn't recognize that the screen was resized and is just using the original width of
the screen to detect when to move the the other computer.

This may also be a race condition since I'm setting up my external monitor about the
same time as I'm starting synergys (both in .xinitrc)

Google user: toddzim

Just wanted to confirm that I am experiencing this issue also.
System: Fedora 11, synergy-1.3.1-12.fc11.i586
Symptom: Login with synergys running. Change resolutions/layouts with xrandr.
Result: Synergy doesn't follow resolution/layout changes, so mouse jumps to external
synergyc based on old resolution/layout points.

Google user: valeuf

I confirm the same issue with xrandr on Archlinux and Mac Os. It is like synergy does
not detect the resolution from xrandr.

Google user: nick.bolton.uk

? ?

?

I would guess that #364 is related. Both would be fixed by doing something when the XRRScreenChangeNotifyEvent is received. I'm not sure if synergyc can resize at runtime yet. Worse case you could "exec argv" ;-)

(maybe useful example http://www.mail-archive.com/sawfish-list@gnome.org/msg03630.html)

I've created and attached a patch (against the latest 1.4 SVN revision) fixing this issue.

0001-Fix-issue-146.patch - Kerrick Staley 16 Feb 2012 03:03

I found an issue with my original patch. The server's mwindow needs to cover the entire display (i.e. it must cover all screens), so when XRRScreenChangeNotifyEvent is received, we have to move/resize mwindow on the server. If this is not done, then when the server is resized to a larger area (i.e. by adding a screen), and the user tries to move the cursor off the server, the cursor will instead warp to the boundary of the original m_window and stay on the server.

I've combined the fix for this problem into my original patch and uploaded a new version.

fix-issue-146_v2.patch - Kerrick Staley 17 Feb 2012 05:12

Added 23 character(s).

Accepted GotPatch

1.4.8

1.3.3

Linux

Thanks for the patch Kerrick. I'm able to reproduce this issue on a default Ubuntu install. I'll give your patch a try tomorrow, and if it works, I'll make sure it's in the next release.

I have an updated version of the patch, but I can't upload it because of an "Internal error".

http://bpaste.net/show/25132/
This patch also handles CRTC changes. I don't know if this will actually make a difference for anyone, but we might as well do it.

Just fixed a permissions issue, uploading works now.

fix-issue-146_v3.patch - Nick Bolton 14 Mar 2012 17:06

Fixed in r1271 -- great work on the patch Kerrick! Thanks again.

GotPatch Fixed

FYI this type of bug when changing display settings under KDE in "kubuntu" 12.10, amd64... going from 1024x768->1280x1024 afterwards the mouse pops over too soon (1280 minus 1024 pixels too soon) and other problems when going down past the Y=768 line and crossing back over when outside the X=1024 line. I have found that simply start-stop synergy (if not running as service, if service then restart the service) this resolves the problem but it is kind of annoying because I run some things in lower resolutions and go back and forth between the two often. The workaround was just to write a script that restarts synergy whenever the display settings are changed, I didn't file this bug because its probably the same as the one posted here, if it's not let me know osrisgothra@ho t m a i l . c o m (email, delinked remove spaces and underscores () )