Package Details: synergy2-bin 2.0.12.beta-1

Git Clone URL: (read-only)
Package Base: synergy2-bin
Description: Keyboard and mouse sharing solution. Synergy allows you to share one mouse and keyboard between multiple computers. Work seamlessly across Windows, macOS and Linux.
Upstream URL:
Keywords: synergy2
Licenses: unknown
Conflicts: synergy, synergy2, synergy2-beta
Submitter: jaap
Maintainer: jaap
Last Packager: jaap
Votes: 22
Popularity: 0.014600
First Submitted: 2017-08-25 15:39
Last Updated: 2018-08-01 11:56

Pinned Comments

jaap commented on 2018-01-17 16:00

!!!!synergy 2 is officially in beta, ill update one more time, and then ill make a new package, something along the lines of synergy2-bin-beta

for any errors, bugs, and other problems with synergy go to the symless forums. for any errors in the pkgbuild, any changes I made in .install, the synergy.service on, or any dependency problem comment here. suggestions are welcome too of course.

I do not work for symless, cannot always update the packages immediately, I don't actually use synergy 2 on a daily basis so flagging the package is the best way to inform me of an update. old versions will still work so you (probably) won't die because of this.(if you do, I sincerely apologize for the inconvenience)

PS. I finally worked out how linebreaks work :)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

colinjmatt commented on 2019-04-25 19:36

The PKGBUILD needs the download link and sha512sum updating to the following:


jaap commented on 2018-08-01 11:58

added a possible partial fix for the XAUTH issue, I cant test it, so if any of you can tell me if this fixed it that would be nice.

EvilBenFranklin commented on 2018-07-24 16:58

Confirmed that setting the synergy.service file as follows worked for me finally:



I tried to get "smart" and set the XAUTHORITY variable as {XAUTHORITY}, but it went back to not fully connecting. Reverted to the above environment variables and it started right up after reloading the daemon parameters with systemctl daemon-reload and restarting the service.

RX14 commented on 2018-06-18 14:12

I can confirm that setting XAUTHORITY in /usr/lib/systemd/system/synergy.service fixes synergy2 for me. For me, xauthority is /run/user/1000/Xauthority, which is a stable location. So I think adding XAUTHORITY as well as DISPLAY to the service in the pkgbuild would be a viable fix.

mertzt89 commented on 2018-06-05 13:38

I was getting this error:

[2018-06-05T07:42:30] DEBUG: XOpenDisplay(":0")<br> [2018-06-05T07:42:30] WARNING: primary screen unavailable: unable to open screen<br> [2018-06-05T07:42:30] DEBUG: retry in 60 seconds<br>

I was able to fix it with the following addition to synergy.service:


"/tmp/xauth-8044-_0" being the contents of XAUTHORITY as my user

Gelmo commented on 2018-05-23 20:45

So it looks like they've reassigned 2.x to beta, and reinstated 1.9.x as the stable release. All 1.9.x stable releases have their synergy-core source representation released in unison on GitHub. Would anyone be interested in a synergy-1.9 package? This would be the release versions of 1.9 core, with an old version of the 1.x GUI built on top.

If you want a simple install that is similar to 1.9, there is already a great option on GitHub, with an aur package - Barrier - Barrier is 1.9.x core with the legacy GUI, but the GUI has been adjusted to remove features that are specific to Symless, such as Activation with a license key. All features are available for free in this version. I figure some people may want to use their valid license, for legal purposes, depending on their work.

Should I create a package for the latest official 1.9 releases, or is Barrier suitable for everyone here?

jaap commented on 2018-05-22 14:06

hmm, this isnt supposed to be a 100% fix, it should get it on urntime.

the only reason I do it like this is because there isnt an actual fix yet, but since the synergy-core itself is opensource you can try to fix stuff youself, just without UI and some extra layers(ssl encryption etc). My display is the default again, so I cant really test this, but if anyone has a better service feel free to tell me.

eschwartz commented on 2018-05-22 13:58

That would explain why it doesn't work, then, since "when you run makepkg it should put the current $DISPLAY variable" has little to nothing to do with the DISPLAY value at the time you run this.

Unfortunately the "fix" is equally meaningless as it too runs during makepkg rather than when it should (during runtime).

The usual workaround for systemd services that need to be aware of the display, is, well, don't do anything. It's handled automatically by /etc/X11/xinit/xinitrc.d/

But explicitly setting the DISPLAY in the service file will break these sort of systemd DISPLAY-aware applications on general principle, for anyone who has a working systemctl user session.

I'm not sure why this runs as a systemd system service instead of a user service, but you'd need to fix that too I guess.

jaap commented on 2018-05-22 13:31

@m3thodic this should already happen, when you run makepkg it should put the current $DISPLAY variable into the service file. if this doesn't work for you, ill test your solution, but I don't see how it doesn't work.

m3thodic commented on 2018-05-20 06:23

Hey @jaap I updated the PKGBUILD to programatically figure out which DISPLAY variable to use as well as removing the external synergy.service (raw) file. I'm not sure how it ended up this way but for some reason my laptop uses :1 for it's main display and my workstation at home uses :0 -- thanks!