Bug #2799 - Right shift broken (Windows server, Mac OS X client)

Status:

Fixed

Priority:

Urgent

Assignee:

None

Category:

None

Target:

1.4.10

Found:

1.3.6

Created by:

Matt Bauman

Created on:

24 Jan 2011 16:46

Updated by:

Nick Bolton

Updated on:

25 Jul 2012 01:06

Platform:

Mac OS X

Google ID:

None

Redmine ID:

2842

Related to: Bug #56 - Mac OS X server not sending keystrokes to client
Related to: Bug #3331 - Key modifiers not working in Eve Online on OS X
Duplicated by: Support #2811 - Server issues Mac&Windows

Steps to reproduce:

Press right-shift modifier plus any key (rightshift-z)

Expected: print 'Z'
Actual: print 'z'

Versions (Synergy, OS):

Server: XP, 1.3.6
Client 1: Mac 10.6, trunk (r894)

Comments:

Note that this is a new regression in Windows server 1.3.6 from 1.3.4. All my modifier keys had been working prior to upgrading the server.

I am unfamiliar with the Windows code, but I did some cursory debugging on the Mac client code to confirm that this is a server issue. With an additional debugging statement in COSXKeyState::fakeKey, I can clearly see the difference between right shift and left shift.

Here I press left-shift z: (shift is code 56, z is code 6)

2011-01-24T11:39:34 FATAL:  56 down  
2011-01-24T11:39:35 FATAL:  6 down  
2011-01-24T11:39:35 FATAL:  56 up  
2011-01-24T11:39:35 FATAL:  6 up

And here I press right-shift z:

2011-01-24T11:41:29 FATAL:  56 down  
2011-01-24T11:41:29 FATAL:  56 up  
2011-01-24T11:41:29 FATAL:  6 down  
2011-01-24T11:41:29 FATAL:  56 down  
2011-01-24T11:41:29 FATAL:  6 up  
2011-01-24T11:41:29 FATAL:  56 up

As you can see, the Windows server is releasing right shift before pressing the key to be modified. And note that this behavior is unique to right shift. All other modifier keys cascade their presses appropriately.

24 Jan 2011 16:57: Matt Bauman wrote a comment.

Indeed, reverting back to Windows server 1.3.4 (without changing the Mac version: trunk r894) solves the issue.

25 Jan 2011 22:34: Nick Bolton wrote a comment.

I was able to reproduce this bug with XP, Vista and 7 as the server. Issue does not occur when server is Linux, so it's a Windows-to-Mac issue.

25 Jan 2011 22:34: Nick Bolton changed Tracker.

Support Bug

25 Jan 2011 22:34: Nick Bolton changed Title.

Right shift broken in Windows Server 1.3.6 Right shift broken (Windows server, Mac OS X client)

25 Jan 2011 22:34: Nick Bolton changed Found in ver.

1.3.6

25 Jan 2011 22:34: Nick Bolton changed Platform.

Mac OS X

25 Jan 2011 22:34: Nick Bolton changed Status.

New Accepted

29 Jan 2011 01:24: Brenden Soares wrote a comment.

confirmed that 1.3.4 works on windows 7. However, 1.3.6 does not.

How soon could this fix be rolled out to 1.4.x?

PS - I'd like to join the development team. How can I contribute?

11 Feb 2011 00:03: Scott Blomquist wrote a comment.

It looks like this bug was introduced in r486. We should try to find a fix to the Remote Desktop issue that this change was trying to fix that doesn't delete the code that fixes this for non-RDP scenarios. I'm happy to help.

I have confirmed that applying the inverse of r486 to the build tagged 1.3.6 or to the head revision fixes the bug documented in this issue report.

11 Feb 2011 22:11: Björn Kautler wrote a comment.

Yes, I also found this regression and the cause Scott is mentioning. I was about to search the bug I wanted to post this in. I'm sure there was another, sooner, one about this bug where I wanted to post a comment but just found this one here. I can also confirm that reverting that commit fixes the issue for me. But actually typing capital letters with the right shift key worked for me, just keyboard selection with the right shift key or reverting the TAB order with the right shift key didn't work for me.

13 Feb 2011 23:05: GreyHound Nono wrote a comment.

I can confirm something similar using a 1.4.1 <> 1.4.1 Setup using XP as Server, Win 7 as Client.
I am able to type uppercase letters using RSHIFT + Key but i can't use RSHIFT + Arrow Keys to select Text or other things (i.e: In Outlook you can select several emails using SHIFT+UP/DOWN).

Using an ordinary USB 102-Key Keyboard from Microsoft.

15 Feb 2011 21:36: Jared Thirsk wrote a comment.

GreyHound Nono wrote:

I can confirm something similar using a 1.4.1 <> 1.4.1 Setup using XP as Server, Win 7 as Client.
I am able to type uppercase letters using RSHIFT + Key but i can't use RSHIFT + Arrow Keys to select Text or other things (i.e: In Outlook you can select several emails using SHIFT+UP/DOWN).

I believe I have the same problem. I am using x86 1.4.1 on two machines, both Win7 x64. Typing uppercase with right shift works, as does shift clicking to select multiple items (I'm using OpenOffice spreadsheet and Windows Explorer), but right shift arrow keys does not work. I just upgraded from an earlier version (1.3.6) hoping 1.4.1 would fix it but no dice.

15 Feb 2011 23:01: Björn Kautler wrote a comment.

@Jared As far as I understood 1.4.1 is not necessarily a more recent version than 1.3.6. 1.4.1 was uploaded January 19th, 1.3.6 was uploaded January 21st. The 1.4 series as far as I understood is the fork "Synergy plus" and not necessarily newer as they develop in the 1.3 stream now. But I may be wrong.

28 Feb 2011 08:37: Frank Oosterhuis wrote a comment.

I can confirm this bug.

Also, middle mouse button and double click seem to be ignored by the guest (OSX).
Is this related?

#10

28 Feb 2011 09:19: Björn Kautler wrote a comment.

@Frank As far as I can tell from the source I don't think so.

#11

28 Feb 2011 11:24: Frank Oosterhuis wrote a comment.

@Björn

Thanks for the quick reply.
I found out I was referring to bug #2763

#12

2 Mar 2011 03:53: Bash User wrote a comment.

I am confirming this bug too on synergy server and client version 1.4.2. I have a windows 7 host and a OSX 10.6.6 client and the right shift will not work. Right shift on its own works, but when adding it as a modifier to any key, the shift is sent first, then the key separately resulting in an unshifted character.

#13

7 Mar 2011 06:22: Anand Sankaran wrote a comment.

Confirm the bug on synergy server and client version 1.4.2, Windows 7 home premium server with Mac OSX 10.6.6 client.

#14

15 Mar 2011 14:20: Marc Kowal wrote a comment.

Confirm the Bug on Synergy Server 1.4.2 Win 7 x64 and Client 1.4.2 WinXP

#15

26 Apr 2011 14:30: Thanh Nguyen wrote a comment.

Confirm the bug on synergy 1.4.2 windows xp 32 bit server and mac 10.6.7 client.

#16

9 Jun 2011 23:15: Daniel Meneses wrote a comment.

I've noticed this bug with windows xp 32 bit (as the server), and Linux (as the client) both running synergy 1.4.2

#17

21 Jun 2011 11:24: D P wrote a comment.

Bug is present:
Client is Synergy 1.3.6 on Win 7 32 bit
Server is Synergy 1.3.6 on Win 7 64 bit

#18

21 Jun 2011 11:32: D P wrote a comment.

Verified on:
Client is Synergy 1.3.7 on Win 7 32 bit
Server is Synergy 1.3.7 on Win 7 64 bit
Bug is still there.

#19

22 Aug 2011 14:21: Blazej Floch wrote a comment.

I can confirm that reverting fixed it.

#20

1 Sep 2011 21:24: Andy Granger wrote a comment.

I'm new here, but I'd like to add my experience to the fray.

My setup is a little different from what's being discussed here, but I'm seeing very similar behavior. Here's what I have:

Mac server (OS X Lion 10.7.1, synergys 1.5.0-r1092)
WinXP client (SP3, synergyc 1.3.4)

I've tried many different combinations of server on the Mac (including SynergyKM which includes 1.3.1) and client on Windows, but I still see the same behavior.

Here's what I'm seeing:

Similarly to what's been discussed here, the right Shift key on the Mac server (Apple Keyboard (full size, low profile keys, current model)) does not get passed to the Windows client. However, rather than seeing the lowercase or non-shift version of the key I wanted capitalized, I get nothing. This also happens with the left Shift key. The kicker here is that either Shift key seems to be behaving as if it was an "Alt-Lock" key (I know there's no such thing). Once I touch either Shift key on the Mac server's keyboard while controlling the Windows client, no text is entered, but menu commands corresponding to the Alt-key equivalent start to function. At this point, if I bring the mouse pointer back to the Mac, no keys work there, either. Also, with a Windows keyboard still connected to the Windows client machine, no text input will work from that keyboard, but the Alt-key behavior happens with this keyboard, too.

The only way I can get proper text functionality back is to repeatedly press any of the Alt keys (either left or right on the Windows keyboard, or either left or right Alt/Option on the Mac keyboard. A single press of any Alt key doesn't seem to fix the problem, only repeated presses. I haven't experimented enough yet to know the minimum number of Alt key presses needed to restore text capability.

Lastly, all text input works normally on the Windows machine's native keyboard both before trying to use the Mac's keyboard with the Windows machine, and after pressing the Alt key several times to fix the problem.

I hope that was clear enough. I also hope that this is the right bug tracker in which to post this issue.

Does anyone have any ideas? I know that OS X Lion is still very new, so I may just have to wait until Lion is officially supported by Synergy.

#21

1 Sep 2011 21:25: Andy Granger wrote a comment.

I think I just down-voted this bug by mistake. Like I said above, I'm new here. Sorry about that.

#22

1 Sep 2011 22:12: Andy Granger wrote a comment.

Crap. I just realized that I made a glaring error in my setup description. My client is actually Windows 7 32-bit SP1, not XP SP3. I work at a tele-radiology company where the platform we deploy to the remote doctors is XP, but we all have Win7 internally. I'm so used to thinking about XP issues that my fingers just followed their muscle-memory. Sorry for the confusion.

Andy Granger wrote:

I'm new here, but I'd like to add my experience to the fray.

My setup is a little different from what's being discussed here, but I'm seeing very similar behavior. Here's what I have:

Mac server (OS X Lion 10.7.1, synergys 1.5.0-r1092)
Win7 client (32-bit SP1, synergyc 1.3.4)

I've tried many different combinations of server on the Mac (including SynergyKM which includes 1.3.1) and client on Windows, but I still see the same behavior.

Here's what I'm seeing:

Similarly to what's been discussed here, the right Shift key on the Mac server (Apple Keyboard (full size, low profile keys, current model)) does not get passed to the Windows client. However, rather than seeing the lowercase or non-shift version of the key I wanted capitalized, I get nothing. This also happens with the left Shift key. The kicker here is that either Shift key seems to be behaving as if it was an "Alt-Lock" key (I know there's no such thing). Once I touch either Shift key on the Mac server's keyboard while controlling the Windows client, no text is entered, but menu commands corresponding to the Alt-key equivalent start to function. At this point, if I bring the mouse pointer back to the Mac, no keys work there, either. Also, with a Windows keyboard still connected to the Windows client machine, no text input will work from that keyboard, but the Alt-key behavior happens with this keyboard, too.

The only way I can get proper text functionality back is to repeatedly press any of the Alt keys (either left or right on the Windows keyboard, or either left or right Alt/Option on the Mac keyboard. A single press of any Alt key doesn't seem to fix the problem, only repeated presses. I haven't experimented enough yet to know the minimum number of Alt key presses needed to restore text capability.

Lastly, all text input works normally on the Windows machine's native keyboard both before trying to use the Mac's keyboard with the Windows machine, and after pressing the Alt key several times to fix the problem.

I hope that was clear enough. I also hope that this is the right bug tracker in which to post this issue.

Does anyone have any ideas? I know that OS X Lion is still very new, so I may just have to wait until Lion is officially supported by Synergy.

#23

7 Oct 2011 22:03: Patrick Walsh wrote a comment.

Just a note that I'm seeing identical behavior here and have tested with 1.3.7 and 1.4.4 (consistent between server and client). I'm running OSX Lion 10.7.1 as the server with a Win7 client, 64-bit.

Various special keys on the mac (shift, ctrl, alt, cmd) either do nothing or randomly map to alt. Once alt is triggered, I can't unstick it without using the keyboard on the windows machine. Experimenting with various mapping commands changes which key triggers alt, but does not achieve anything. For just lower case characters and mouse, things work great.

#24

14 Nov 2011 22:42: Collin Anderson wrote a comment.

I'm having a similar problem on synergy v1.4.4. windows to windows.
+arrow keys to select isn't working, but + letters works fine.

#25

5 Jan 2012 03:07: Matt Bauman wrote a comment.

Ok, I've spent some more time looking into this issue.

The patch from r486 does indeed cause this issue. It was applied in response to Issue #272. It basically removes all knowledge of a right-shift virtual code on MS Windows. I find these comments somewhat interesting:

??"What purpose had the special handling? Does removing it create other problems?"??

??"I have no idea what the special handling code was for."??

Yes, yes it does cause other problems. When the server goes to poll which modifier keys are down, it determines which physical button is mapped to the virtual code and then checks to see if that button is down. When the VKRSHIFT is set to VKLSHIFT, it only checks to see if the left shift button is down upon receiving any shift virtualkey code. Thus, it will always unset the right shift key when attempting to use it as a modifier. I haven't traced the rabbit the whole way down the hole to see why this doesn't break Win Server -> Win Client connections, but I suspect it's due to the fact that both server and client only have knowledge of a VK_LSHIFT.

I find it somewhat amusing (or frustrating) that Issue #272 was introduced to fix a bug in WINAPI's getKeyState without an understanding of what the code does or recognizing that it breaks all the other clients. If -- if -- you wish to fix this bug on Microsoft's behalf, do it in the Windows client (CMSWindowsKeyState::fakeKeyDown; just switch VKRSHIFT to VKLSHIFT there), not in the shared server/client code.

#26

30 Jan 2012 21:45: Jason Brockdorf wrote a comment.

Synergy 1.4.5
xp pro 32-bit sp3 server + xp pro 32-bit sp3 client + win7 64-bit client

I've found that although the right shift key will allow me to type a capital letter (or lower case if caps on) on the clients, it doesn't allow me to send a SHIFT + TAB to tab between fields in reverse order.

#27

31 Jan 2012 03:05: Matt Bauman wrote a comment.

Applying the inverse of r486 to the server fixes Jason's issue, too. Test setup:

32-bit WinXP client v1.4.5 with r486, 64 bit Win7 server, v1.4.5 with r486: right-shift-tab fails, sends tab instead
32-bit WinXP client v1.4.5 with r486, 64 bit Win7 server, v1.4.5 without r486: right-shift-tab succeeds

#28

4 Apr 2012 16:09: Matt Edwards wrote a comment.

OK, where are we with a fix for this please? any progress?

#29

12 Apr 2012 19:19: James Valero wrote a comment.

I'm getting the same issue, it was working before in an earlier release (pre 1.4.8) but it seems to have come back.

#30

13 Apr 2012 23:52: Chris Jurney wrote a comment.

I'm seeing this with a Win 7 server version 1.4.8, Mac OSX 10.7 client version 1.4.8.

#31

14 Apr 2012 21:47: Jeffrey Cross wrote a comment.

I experienced this after upgrading to Mac OSX 10.7 Client 1.4.8 and Windows XP Server 1.4.8. It appears to be the OSX client side: downgrading the server had no effect but I'm now running 1.4.8 Win server with 1.4.7 Mac client and back to normal. "Normal" in that both shift keys work EXCEPT for Shift+Tab, which only works for the Left Shift key. Right-Shift+Tab engages a normal Tab.

#32

19 Apr 2012 18:50: Randall Cameron wrote a comment.

Adding my support. Windows 7 x64 server running 1.4.8, OSX 10.7.3 client also running 1.4.8.

#33

20 Apr 2012 15:22: Giorgio Galante wrote a comment.

Adding my support as well. Windows 7 x64 server running 1.4.8, OSX 10.7.3 client also running 1.4.8.

#34

21 Apr 2012 15:10: Matt McGill wrote a comment.

I can also confirm. Win XP SP3 Server running 1.4.8, OSX 10.6.8 client running 1.4.8: Right shift doesn't work. Downgrading OSX client to 1.4.7 resolves the problem.

#35

23 Apr 2012 16:20: WizOne Kaland wrote a comment.

This happens for me on an Ubuntu 10.04 LTS client as well, so not limited to Mac OS X (though it also happens on my Mac OS X client).

#36

23 Apr 2012 16:20: WizOne Kaland wrote a comment.

Sorry - meant to say Ubuntu 11.10 (Mint 12 KDE) client.

#37

24 Apr 2012 06:37: Tommy G wrote a comment.

I experienced the same issue using server: Windows 7 x64 Pro SP1 and client: OSX Lion 10.7.3 (both using Synergy 1.4.8). Reverting just the OSX client back to Synergy 1.4.7 fixed the problem for me.

#38

6 May 2012 16:44: ben Jackson wrote a comment.

I can confirm this issue using windows 8 consumer preview and mac osx 10.5.8 (see the lack of captilization in this sentence). I am using 1.4.8. I will try regressing to the 1.4.7 build and see if this fixes this issue.

#39

9 May 2012 09:12: Mark Daniel wrote a comment.

Again I confirm I am seeing this as described

Windows 7 64 bit, Apple full size UK USB keyboard, Synergy 1.4.8, Running as Server
Mac OS X 10.7.3 Lion, Synergy 1.4.8, Running as Client.

11 May 2012 12:20: Nick Bolton changed Target.

1.4.9

#40

11 May 2012 12:20: Nick Bolton wrote a comment.

Confirmed, seeing this on OSX 10.8 with 1.4.8.

11 May 2012 14:11: Nick Bolton changed Priority.

Normal Urgent

#41

19 May 2012 20:28: Angela Rogers wrote a comment.

I have this same issue on Max OS X 10.7.3 client with Windows Vista Home server using Synergy 1.4.8.

#42

19 May 2012 20:29: Angela Rogers wrote a comment.

Angela Rogers wrote:

I have this same issue on Max OS X 10.7.3 client with Windows Vista Home server using Synergy 1.4.8.
I should say Windows Vista server is 64-bit.

#43

21 May 2012 07:01: Jacob Qiang wrote a comment.

Confirmed this.
Server: win7 64; client: OSX 10.7.3
Both using Synergy 1.4.8.

#44

30 May 2012 02:24: Paul Jorgensen wrote a comment.

If you use AutoHotKey (AHK) there is a work around until the fix is applied.

Create a new AHK script or edit your existing script to add the following lines:

#InstallKeybdHook
RShift::LShift

For more information, see my post at http://prjorgensen.com/2012/05/29/right-shift-broken-in-synergy/

BTW, I have a Windows 7 64-bit Synergy server and a Mac OS X 10.7.4 Synergy client both running Synergy 1.4.8. I have not tested this on any other configuration. Please let me know your results.

#45

1 Jun 2012 08:49: Brian Hong wrote a comment.

I can confirm this bug on 1.4.8. (It worked in 1.4.7) And the bug's origin is indeed r486.

It was reintroduced in r595 where 1.3.5 r484:487 was merged into 1.4.1 branch. (Which became 1.4.2)

One weird thing is, I was using synergy with no problems in 1.4.7. Why is it reintroduced in 1.4.8?

#46

11 Jun 2012 19:05: Brian Herold wrote a comment.

any news on this/ all punctuation and capitalization is due to my right shift key not working ;0

#47

13 Jun 2012 16:22: Adam Cowley wrote a comment.

I was able to solve this on Ubuntu 12.04 (both machines, 4 monitors) by rolling back Synergy to 1.3.8 and then using "apt-get hold synergy" to keep it there. Completely solved the problem for me.

#48

15 Jun 2012 03:36: Dale Higgs wrote a comment.

Confirmed bug AND AutoHotKey work-around:

Server: Win7 x64 1.4.8 Client: Win7 x32 1.4.8

@Paul, thank you for the workaround. I can't believe I didn't think of that myself!

Looking forward to 1.4.9 :)

#49

7 Jul 2012 16:42: Claudio Musso wrote a comment.

Instead of using a script to solve the problem. Considering this bug keep coming from version to version, until solved in reliable way, we need a fix in the server configuration same as the Caps Lock and other Keys fix, the fix should send Left Key(wich is always working) instead of the Right Buggy Shift. This also implemented like a check-able fix should be neutral to those who didn't report any trouble with it.

#50

8 Jul 2012 06:16: Stephen Raub wrote a comment.

I have this same issue, and tracked the breaking change to revision 1272. Reverting this revision fixes broken right shift problem.

#51

9 Jul 2012 10:57: Wojciech Sierakowski wrote a comment.

Indeed, very annoying bug. Happens to me on Win as server and Mac as client. 1.4.8

#52

9 Jul 2012 15:27: Wouter Westenbrink wrote a comment.

AutoHotKey work-around was not working for me (server: win7 x64 1.4.8, client: os x 10.7.4), KeyTweak (mentioned in old thread) did work

#53

9 Jul 2012 18:04: Drew Nall wrote a comment.

Duplicated bug.
Server: WinXP SP3 x86 Synergy 1.4.8
Client: OSX 10.7.4 x64 Synergy 1.4.8
Downgrading client to 1.4.7 resolved the issue.

#54

12 Jul 2012 16:19: Sam Jenkins wrote a comment.

Thank you for the "(server: win7 x64 1.4.8, client: os x 10.7.4)" comment.

15 Jul 2012 00:49: Nick Bolton changed Target.

1.4.9 1.4.10

#55

17 Jul 2012 22:35: Kirk Ruff wrote a comment.

I cannot find a ticket with my exact setup, but it's the same issue with different client/host so I'm posting here instead of opening a new ticket. This issue has been going on for a number of revisions

Host: Windows 7 64-bit, Synergy 1.4.9

Client: Windows XP 32-bit, Synergy 1.4.9

Both fully patched. Wonderful software btw. Leaps and bounds beyond anything similar.

#56

23 Jul 2012 21:06: Joel Foote wrote a comment.

I see the same issue with Windows 7 64bit, 1.4.9 and Mac OS X 10.6.8 with synergy 1.4.9.

I have an old version of the client (synergyc-patched 1.4.6, protocol version 1.4) that I used instead on the mac side, and it works fine keeping 1.4.9 on the Windows 7 side.

#57

25 Jul 2012 00:45: Nick Bolton wrote a comment.

The problem is simple. For me this only affects Windows server + Mac client config. Any other OS as server works fine.

The cause: A fix was made to OSX in r486 to fix a bug where shift was intermittently not being pressed. This used the modifier mask sent with the key instead of the actual shift key press (sent before the 2nd key). This new behavior will remain the same.

The fix: There is a bug in the Windows server which fails to set the shift bit in the modifier mask which is sent along with another key. This only happens with the right shift key. The solution is to fix the Windows behavior.

We aim to fix this for 1.4.10.

#58

25 Jul 2012 01:04: Nick Bolton wrote a comment.

Just read comment #25 -- Matt is right, and the remote desktop bug perhaps should be been solved differently. I have reverted the patch, and right shift now works from Windows server to Mac client.

Sorry this fix took so long and thanks to Matt for doing the detective work.

25 Jul 2012 01:06: Nick Bolton changed Status.

Accepted Fixed

#59

25 Jul 2012 01:07: Nick Bolton wrote a comment.

Fixed in r1562 -- will be available from the nightly builds and in 1.4.10 release.

#60

22 Aug 2012 11:25: Gustav Nyberg wrote a comment.

I am still experiencing the same problem as described in this bug.

I am running the lastest version (1.4.10) on both server and client.

Server is a Win 7 machine and the client is a Win XP machine.

I am trying to remote a Win 2008 server.

Kind regards Gustav

#61

29 Aug 2012 07:33: 波余 wrote a comment.

bug still exist in 1.4.10.

#62

4 Sep 2012 14:49: Jordan Wisniewski wrote a comment.

Fixed for me in 1.4.10. My setup is: Server: Windows XP 32-bit (1.4.10) Client(s): Ubuntu 11.04 (1.4.6)

#63

7 Apr 2013 05:11: Ben Axnick wrote a comment.

This bug (or some variation of it) very definitely still exists for me, going from a Win7 x86 server => Win7 x64 client. Both are running 1.4.10. The main possible point of difference for me would be that I use a key combo to shift between systems rather than having it happen automatically through mouse movement.

#64

7 Apr 2013 06:00: Ben Axnick wrote a comment.

As suspected, the problem was directly related to the key combination I was using to switch screens. My key combo to switch system was "Ctrl+Alt+Shift+Left" on account of not wanting to accidentally interfere with any existing combinations. Changing the key combo to "Ctrl+Alt+Left" resolved the problem.

Interestingly, before changing the key combination, using the AHK script "RShift::LShift" resulted in neither shift modifier working at all on the client synergy system, except as part of the key combination to switch back to the server system.

This definitely doesn't warrant a re-opening of the bug, as it's obviously a different issue (with the same symptoms). May be worth a separate bug filing though.

Write comment