Package Details: synergy2-bin 2.0.12.beta-1

Git Clone URL: (read-only, click to copy)
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.000000
First Submitted: 2017-08-25 15:39
Last Updated: 2019-10-05 12:05

Pinned Comments

jaap commented on 2019-10-05 12:15

Hey guys, sorry for not really maintaining this package. Synergy 2 is never going to become a real product, this version is not supported anymore. Although you can of course still use it if you have the license and everything works for you. This will be the last update I will do to this package, as it is the last update.

From unofficial sources I have heard that everyone who owns a valid synergy2 license will get a valid license for the next major release.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

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!

jaap commented on 2018-04-28 18:49

@galvez_65, yeah that is indeed correct, I dont know if arch helpers automaticly switch packages if a merge happens on the AUR, but to be sure just install synergy2-bin, it conflicts with synergy2 so you might have to remove that first.

galvez_65 commented on 2018-04-27 13:44

@jaap so I guess the proper thing to do at this point it to uninstall synergy2 and install synergy2-bin

eschwartz commented on 2018-04-25 20:16

jaap commented on 2018-04-25 20:16

@galvez yeah, I asked myself the same question yesterday evening :)

because synergy2 and synergy2-bin are basically the same(except one includes beta releases, but this wasn't really made clear in the pkg description). so @Eschwartz merged them. the rules for -bin, -git and -beta aren't made clear anywhere as I am aware. this will be the main stable release version, and synergy2-beta-bin will be for the beta's (ill make that one later, no real betas atm)

galvez_65 commented on 2018-04-25 20:08

what happened to synergy2? looking just now its gone and I only see suynergy2-bin

eschwartz commented on 2018-04-24 21:03

You neglected to update the .SRCINFO

Note this can be easily automated using e.g.