Synergy

Google user: Logan.Freer

I've had something similar happen to me as well. Not sure if they might be related.
When copying and pasting between screens, I tend to leave the ctrl key pressed down.
When I switch screens, with the ctrl pressed down, it acts as though the key is still
pressed down on the screen I moved from. I then have to press the ctrl key to get it
working again.

I've noticed it happens with any key that is pressed. As well, it doesn't matter if
it's from server to client, or from client to server.

Google user: stag.stag.stag

I will have to wait until I go home to test if that is the case for me too.

Either way, should the expected output for your situation be that if you switch to
screen #1 while not holding any buttons then screen #1 will know that you are not
holding any buttons (regardless of the state when you last switched from #1 to #2)?

Google user: Logan.Freer

Yeah, that output sounds right to me.

I'm also curious to know if this is related to your problem, and if you were able to
reproduce it. I can confirm that I am able to reproduce it on two Windows XP SP3
machines.

Google user: Lithium07

I can also confirm this problem. It happens to me under Windows XP, Linux and Mac OS X. Here the ALT key is
stuck and i have to press it for a normal working keybooard...

Google user: sorin.sbarnea

New Accepted

Google user: sorin.sbarnea

This bug is driving me crazy but it's interesting that I found that on my computer it
does reproduce, very often, only on the server. I wonder how I would force synergy to
reset all the modifier states when it does switch.

Google user: iamalanho

I have the same exact issue. It's usually with the super (Windows) key. I've also
noticed that when this problem occurs, both the T and C keys will no longer register
when typing in Outlook and I will need to restart Outlook to gain those keys back.

If this could get resolved, it would be great.

Google user: jla...@gmail.com

I get lot of this "ALT key gets stuck" problem when running synergys.exe on WinXP.

Often when this starts to happen, pressing Alt fixes it but very soon the problem
manifests again (e.g. after switching windows with Alt-Tab), and I have to press Alt
once again. Quitting synergys.exe and starting it again helps.

The stucking key problem happens even without switching the desktop at all.

Google user: sorin.sbarnea

Normal Urgent

?

Google user: ewright626

In my scenario my Synergy Server is a WinXP sp3 box and I use a Fedora client and a
Mac osX client. On both clients and not the server the meta-key is depressed for
every keystroke unless I manually depress the ctrl- key and then I am able to enter
normal characters. this just started today and was erratic for awhile, but now seems
to be permanent. restarting synergy does not seem to improve the situation. when
debugging the log shows for instance that key "j" being 106 on server machine, when
pressing key "j" on client the log shows that it is sending key 106 to client. seems
very odd.
thanks
-eric

Google user: surge3

OMG, this has happened to me so many times and now I know the cause...
Sometimes my control + alt keys stick from screen to screen....I guess It's because
I am holding them down while switching screens?

Google user: jla...@gmail.com

surge3, at some point I also thought that would be the cause, and started to be
careful when switching screens. But no, at least for me that isn't the core issue.

Like I said, sometimes the alt key starts being "stuck" even if I haven't switched
from the server to a client in a long time. Pressing it once helps, but then very
soon it usually happens again e.g. after alt-tabbing. When this starts to happen, I
usually restart synergy and then the problem goes away again.

Google user: sorin.sbarnea

I think that this could be the result of loosing packets for some reason?

Google user: jla...@gmail.com

sorin.sbarnea:

I guess that may be the case when this bug manifests in connection with a client
screen or switching screens.

However, as I said, I get this stuckiness problem also without using client screens
at all for a long time (i.e. when using only the server desktop). And when that
happens, I can fix the problem by restarting the synergy server (running on Win XP).

It is possible we're talking about two different bugs here -- one which manifests
inside the server machine, and other which is connected to client machines and
switching screens.

Google user: nick.bolton.uk

Google user: nick.bolton.uk

Google user: malvineous

Ah, this bug has long bothered me with the original Synergy - glad to know that this
fork might fix the bug!

For me, with a Linux server and Windows XP client, the problem is 100%% reproducable
by locking the Windows PC (by pressing Win+L), then moving to Linux (without holding
any keys down) and pressing Win+L to lock the Linux PC.

Later, putting in my password to unlock Linux, moving across, pressing Alt+Ctrl+Pause
and putting in my password to unlock the Windows machine all seems fine, except the
Windows key ends up being stuck down 100%% of the time. If I press 'e' then Windows
Explorer loads for example.

To fix the problem pressing both Windows keys usually fixes it, although sometimes
other random keys are held down, sometimes it is Escape which means drag-and-drop
stops working under Windows. Pressing Alt+Ctrl+Pause then Escape seems to reset
things most of the time.

Because I'm on a LAN and this happens 100%% of the time I doubt it's a packet loss
issue, I think it's more related to Synergy sending a keypress event but forgetting
to send a corresponding keyrelease event.

Google user: nick.bolton.uk

I have just experienced this issue; it occurs on the computer running synergys. For
some reson, pressing the shift key doesn't cause it to become unstuck. The way in
which it affects me is that when I scroll, the shift key appears to be stuck on
(meaning that zoom occurs in web browsers, instead of scrolling) and the only
solution seems to be restarting synergys.

Also, I've renamed the title to make it more general; hopefully this will attract
more relevant users to the topic.

Google user: sebflipper

I have this issue as well with 2 computers running Windows XP pressing and holding
Shift/Ctrl/Win/Alt does not seem detect the key release when switching between
computer and pressing Win+L.

Google user: malvineous

Just to clarify (for workarounds), the problem is that one or more of the PCs don't
receive the "key released" event. So in order to fix the problem without restarting
synergy you need to manually send a key-release event yourself, by pressing (and
releasing) the affected key. Holding the key don't won't help, and holding multiple
keys down is less likely to work. The ideal workaround is to press and release
each modifier key (shift, ctrl, etc.), one at a time, until the problem goes away.
Also don't forget that if your right-shift key is stuck, it doesn't matter how many
times you press and release the left-shift key...so remember to do both sides of the
keyboard.

Sticky meta keys problem

Google user: nick.bolton.uk

Meta keys (shift, ctrl, alt) stay on even though not pressed (sticky meta keys)

Google user: aidin.fanni

My setup:

client is always a linux redhat, has been an AS4 is now a WS4.
Server has been a windows xp, windows vista and now a windows 7 machine. Different
patch levels.

When this happens i just smash alt ctrl shit and meta key a couple of times and it
goes away, but it is quite annoying.

I havent been able to reproduce it on demand, but it happens like stag.stag.stag said
around 5-10%% of the times i move from client to server. It only happens when i move
from the client to the server, not the other way around.

Google user: sorin.sbarnea

I've found something very interesting about this bug and I want other to confirm or
not this discovery. I discovered that the sticky key behavior can act on a single
application from the synergy server.

For example if I'm using 3 applications: firefox, pidgin and explorer and the sticky
key starts on pidgin I will be able to use the others apps without problems. From my
point of view it looks like the sticky-key is per-app. BTW: until now I've found this
behavior only on pidgin and firefox.

Google user: sorin.sbarnea

I've found something very interesting about this bug and I want other to confirm or
not this discovery. I discovered that the sticky key behavior can act on a single
application from the synergy server.

For example if I'm using 3 applications: firefox, pidgin and explorer and the sticky
key starts on pidgin I will be able to use the others apps without problems. From my
point of view it looks like the sticky-key is per-app. BTW: until now I've found this
behavior only on pidgin and firefox.

Google user: surge3

I Can't confirm or deny your claim, but what I can say is that I have none of those
apps installed on my windows box (I use opera, and AIM 5.5, and IE is removed), and
the issue still happens.

Google user: malvineous

That's also odd because if the problem is on the synergy server (the PC with the
keyboard plugged in) then it's more of an OS or application issue (perhaps you held
the key in that app, moved across to another PC and let go of the key, but because
synergy had the keyboard grab the app didn't get the key release notification.)

Certainly for me I never have any problems with stuck keys on the server, it's only
on the client PCs.

-Missing comment-

Google user: nick.bolton.uk

d3faultdotxbe,

Thanks for your post. Please refrain from using swear words, as some users are
offended by this sort of language.

As for the link you posted, how does this relate to Synergy+? I did a page find with
the term "synergy" but couldn't find anything. Is it a comment you are referring to?

Nick

-Missing comment-

Google user: silkman

Hello everyone,

I stumbled on this one as this problem has been long going on for me. I can confirm
that it is quite random (ie not reproducable on demand) but happens more than a few
times each day.

To clarify: The problem is that alt, ctrl or shift sometimes are left "on" and I
need to press all of them once (6 keys in a regular keyboard) to unstuck the
offending key.

The funny thing is that apart from the workstation, this has been happening in my
dell laptop as well as my previous dell laptop! Since this has been bugging me for
about two years in 3 machines I was afraid it could be a virus, don't know just a
thought...

And of course I have never used synergy plus; so I guess this should be a general
windows bug...

George

Google user: jla...@gmail.com

silkman/George: You're right, this is something which does happen on all PC hardware
every now and then, and it has always been so.

However, Synergy makes the problem happen clearly more often.

Google user: ristomatti.airo

jlauha: Meta key locking has never happened to me without Synergy.

Also as a side note easiest way to get the meta keys stuck with Synergy is to use
keyboard shortcut to jump to the other screen. For me that feature is basically
unusable because of that. Keys get stuck quite often even without that though.

I've tried adding send of keyrelease events for all the meta keys to the screen
switch hotkey but it hasn't helped which is quite interesting also.

Google user: edw...@carrel.org

Interesting.

I have been able to reproduce this issue on my setup with pretty decent regularity:

• Server: Ubuntu Jaunty, running the head of the synergy tree
• Client: MacOS 10.5.7, running the head of the synergy tree

Steps:

1. Start with mouse over on server screen with no keys held down.
2. Press and hold down two or more modifier keys. Keep held through the following steps.
3. Move mouse from server screen to client screen.
4. While on client screen, press a key, preferably one that will not cause any action
   within the active application given the modifiers pressed.
5. Release the modifier keys.
6. Press the same key again. Watch as the machine behaves as though at least one
   modifier is still down. Press different keys (still being careful to not send the
   active application spinning) and see them react the same way.

Though not perfectly repeatable, I have been able to get at least one modifier stuck
around 80%% of the time doing this.

Given that this is affecting people of all platforms, my attention has been turned
immediately to synergy/CKeyState.{h,cpp}. The class defined in this file is
responsible for responding to keystrokes, passing those events down to the platform
dependent handlers, and keeping track of key states (surprise), including the state
of the modifiers. The internal modifier state within the CKeyState object seems to be
correct as I watch it react to me pressing and releasing modifier keys, but given the
chatter on this issue and my own experiences, that same state updating is not
consistently making it down to the respective operating systems. Pressing the stuck
modifier key down on either the client or server seems to be enough to unstick things.

The way CKeyState, and its progeny, handle this sort of stuff anyway is just
bizarre. It seems to store the same information for certain things more than once.
The subclasses of it for each platform are just a scary hodge-podge various bits of
state with lots of moving parts. I get an intuitive sense things could be simplified
a lot here. It would make future bugs like this hopefully a bit easier to track
down.

Anyway, I'll keep researching, and see if I can track down on my MacOS machine where
the "key up" event is getting interrupted and thrown away.

Google user: kenn...@telus.net

In my case I had a sticky right-shift modifier when I switched to my client. A
simple hotkey configuration that removed using the shift fix solved the problem:

Old config:
SHIFT-CTRL-OPTION-LBRACKET switch to client

New config (no more sticky-shift):
CTRL-OPTION-SUPER-LBRACKET switch to client

Google user: syed.a...@gilani.eu

Google user: blaze.k...@gmail.com

I've also been getting this problem, since I set ctrl+shift+<right/left> to switch
between linked computers. Any one of alt, shift or ctrl can then be stickied,
seemingly at random. Pressing the keys again unsticks them. I'm running an XP host
and Ubuntu 9.04 client if it helps.

Thanks for the tip #34, I'll try it and see if it helps.

As a separate, but maybe related problem, I also use ctrl+alt+ to switch
desktops on the Ubuntu client. When I switch to the client and then try to switch
desktops leaving the ctrl key pressed, it doesn't register. That is, I have to
release it, and then press it again to use it to change desktops.

Google user: joshbenner

I experience sticky meta keys on client when NOT switching. This happens at a
frequency of about once every 10-15 minutes as I'm typing on the client machine. I
have not found a definite means of reproducing. Server: Vista 32, client: OS X
10.5.7, both running Synergy+ 1.3.4.

I think this is actually a separate issue from what is mostly being discussed in this
issue, which is sticky metas resulting from holding a meta while switching between
client and server. Should we create a separate issue (does on already exist?)?

Google user: ristomatti.airo

joshbenner: I'm not saying it might not be a different problem in the code but just
to clarify - for me it has never been only a problem of holding meta keys while
switching, but it just makes the bug more likely to come up.

Google user: nick.bolton.uk

We should keep all 'sticky meta key' comments to this issue, regardless of how each
scenario is reproduced.

Google user: joshbenner

I believe the issue I'm encountering is more related to Issue #7

Google user: nick.bolton.uk

Hmm, yes could be, the two issues are closely related. When I experience the issue the
meta keys still work (indicated by cursor change).

Google user: richfletcher

Comment 17 by malvineous I can concur with, regarding the reproducing of the bug.
Here's my results:

Locking the client with win-L (either left or right key has same result), lock server
with Win-L, unlock server, unlock client: windows key stuck on client.

Locking client with win-L, immediately unlocking: no stuck key.

Locking client with win-L, moving mouse pointer over to server machine and back,
unlocking client: stuck key

Locking client with win-L with the cursor in a text box (this textarea actually, in
firefox), moving pointer over to server machine and back as in last test, unlocking
client: no stuck key!

**NOTE: the above stuck key behaviour only happens when the windows key is released
*before the L. If I slowly hold down the windows key, press and release the L, and
then release the windows key the stuck key does not happen!

Google user: richfletcher

To clarify the above comment: the order of the windows-L key releases does not seem
to matter; what seems to matter is how fast they're released. If I, say, [press
windows], [press L], [release L], [release windows] quickly enough I can trigger the bug.

Google user: jeworley

Until tonight I'd had this happen zero times, but out of nowhere and with no software
configuration changes I am now getting this 100%% of the time. I use a lot of macros
which switch quickly between two computers, and every time I select the second the
left Alt key jams and will not allow me to switch back to the primary screen until I
manually press that key.

Is there an expected fix on this at any point in the future? I'm dead in the water
with 100%% Synergy failures until a patch is released.

Google user: nick.bolton.uk

jeworley: I'm sorry to hear you've hit a brick wall with this issue. Currently, it's
our most critical bug fix - however it's also one of the most difficult to investigate,
so it could be some time before we get a fix out.

Which version are you using? Have you tried both 1.3.3 and 1.3.4?

Google user: jeworley

I started having the problem with 1.3.1 tonight, and it also happens in 1.3.3. I just
tried 1.3.4 as well, which I can't verify because screen switching doesn't seem to
work in 1.3.4. I have configured PgDown to quick-switch to computer 2, then PgUp to
come back, with various quick scripted keys in between, and to keep errant mouse
clicks from interfering lock the mouse from crossing the screen borders with Scroll
Lock. Apparently in 1.3.4 the Scroll Lock key no longer locks the screens, and my
switch keys aren't working working at all either.

I think I may have stumbled onto something interesting as well though. Up until
recently I had literally never seen this error a single time, in months and months of
constant use. I had thought that nothing changed on either machine, but in digging a
little deeper found that DirectX 9 was installed on the client machine about an hour
before this problem started happening. I don't know if that has anything to do with
anything, but it's the only modification made to either machine since a set of
patches around the middle of last month.

Both the server and the client are XP SP3.

Google user: nick.bolton.uk

Hmm, very interesting point about DirectX - it should be unrelated; but perhaps it
changes some of the Windows API messages, or introduces new ones? Just a complete stab
in the dark there.

Google user: jeworley

I thought the same thing about DX9 - it doesn't seem like a likely candidate for
causing problems, but it's a starting point.

I also figured out the failure to screen-switch in 1.3.4 was on my end. After several
uninstalls and reinstalls of different Synergy/Synergy+ versions Windows needs a
reboot to make everything act normally again. The upside is that 1.3.4 works as
intended. The downside is that it still seems to lock the alt key 100%% of the time.

I'm about to format the client machine and reinstall XP sans DX9 redist to see if
anything comes of it.

-Missing comment-

Google user: nick.bolton.uk

Issue #6 may help as a work around.

Google user: nick.bolton.uk

Sorin: Are we definitely able to fix this for M1 release? Should it be moved to M2?

Google user: Oleg.Semenov

I've recently switched from original Synergy to Synergy+, hoping to fix this issue,
and it seems to me that this problem occurs much more often with S+.

-Missing comment-

Google user: nicolas.ramz

Well, just to let you know I confirm the problem, both in Synergy, and Synergy +.

Server: WinXP,
Client: MacOSX

Couldn't it simply force of release of each key when switching desktops ?

Sounds logical to me.

Google user: m...@halfzero.net

FWIW this may be solved once the unified GUI interface gets started/finished. I say
this because I use SynergyKM for Mac and it runs synergy in interactive mode to
capture the log messages. You don't really notice a difference because it's all
handled in the background, but it's a good way for the GUI to keep track of what's
going on.

I made symlinks to the Synergy+ binaries for SynergyKM to use and it doesn't quite
know when it's got an established session (I'm guessing because some of the console
messages aren't what it's expecting) but it works just fine.

Just my $0.02

Google user: edw...@carrel.org

@nicolas.ramz: The problem doesn't manifest as soon as the cursor is panned across;
the symptom is triggered only after a character is pressed while the modifiers are
still held down. Internally, what synergy seems to do is to press the modifiers
only as long as they are needed, and then release. Somewhere in there, one of the
modifiers is failing to be released. Patch over solutions, like forcing the keys to
release whenever we might have the slightest inclination that there is a problem are
just bound to create maintenance nightmares in the future, and we have enough of
those now. ;-)

@everyone: There is one orientation no one here seems to have tested yet, and that is
Linux as a client. So, here's my setup:

Server: MacOS OS 10.5.8 running "/p/synergy-plus/source/detail?r=924f4daa2048":revision 924f4daa2048
Client: Ubuntu Linux 9.04 running "/p/synergy-plus/source/detail?r=924f4daa2048":revision 924f4daa2048

Same reproduction steps that seem to produce the issue on MacOS as a client. Same
steps which appear to reproduce the issue on Windows. I can not reproduce the issue
on Linux. If my previous train-of-thought was correct, and KeyState.{cpp,h} was
producing this issue, it would seem logical that it would appear on Linux as well.
This doesn't remove these files from consideration; all of the platform specific
key-state management classes inherit from this one class, and so it is possible that
the Windows and MacOS files call a method that the XWindow code doesn't, but that
does mean our collective attention does not want to be drawn entirely away from the
two platform specific files.

FWIW, using the same revisions, I can still reproduce the bug reliably going the
other direction. :-(

Google user: maulkin

Ok, glad this has been brought up here.

This is an issue which has been going on for 'some time'(tm).
It seems to be an issue with how keys are received, and what happens when a key is
received twice in quick sucession.
What seems to occur, is that instead of receiving a key down/key up/key down/key up,
the client gets key down/key down/key up/key up. Have a look for
"CXWindowsKeyState.cpp,208: 073" lines in the attached file.
I think that the code stores the state insternally of 'down and up' for each key.
When a down is received, a flag is set. When an up is received, the flag is cleared,
unless it's already 0. This means that the second up event is ignored.

Neil

Google user: crazygeorge

I've had good luck by adding fakeAllKeysUp() when the client gets a key up with no
key down. It's not the proper solution, but seems to work...

void
CKeyState::fakeKeyUp(KeyButton serverID)
{
// if we haven't seen this button go down then ignore it
KeyButton localID = m_serverKeys[serverID & kButtonMask];
if (localID == 0) {
+ fakeAllKeysUp();
return;
}

synergy_sticky.txt - 27 Aug 2010 23:33

Google user: edw...@carrel.org

@maulkin: More details on your setup would be extremely helpful. Specifically, the
operating system on the machine running synergys, and on each of the machines running
synergyc. Knowing more about your setup would let me know how much to blame on the
line of code you pointed out.

@crazygeorge: Does it reduce the occurrence of this issue, or completely eliminate
it? Given the evidence I've found, it would suggest that the problem is in
platform-specific code; your code patch would suggest otherwise. I suspect knowing
the success rate would help pin down which section of code is causing the problem.

Google user: maulkin

Hi,

This is running both the server and the client on Debian Lenny.

Google user: crazygeorge

It almost fixes the problem... but with some quirks. It gives me a way that I can
reset the status of the keys when they get stuck. Not optimal, and a big guess, but
since this annoyance happens to me about once a day, and I'll take what I can get.

I notice that with the change, if I hold down left shift while switching between
machines, then the next time I press right shift, right shift will be stuck. I have
to go back to the server and hit the shift buttons to reset them.

My setup is synergys on winxp, and synergyc on linux.

Google user: blaze.k...@gmail.com

It might be relevant that synergy is also not keeping track of when the meta keys are
being held down. I'm still using the same setup, XP server, Ubuntu client, and if
I'm using a key combination that requires + to be held down while the
arrow keys are being changed (for example, this is how you change language input in
Ubuntu), it doesn't register that they're still being held down. In other words, I
have to release + and press them again each time I want to change the
arrow key.

This is not a problem using the key combination though, as I can hold that
down and change arrow keys (for changing my workspaces) without having to release it
each time.

Google user: richfletcher

OK, don't know if anyone cares, but comment 42 and 43 (testing stick windows key
after lock) were actually tested with 1.3.1 (Synergy2) not 1.3.4 (Synergy-plus).

1.3.4 is different in that once I lock the client, I lose keyboard/mouse control of
it--so I can't exactly test it well. The 1.3.4 server does not seem to have the
same sticky windows key on lock behavior described above .

Google user: daedalus.infin1te

I'm getting this same issue. I have two different setups

Setup #1
- Ubuntu 9.04 - Linux HOSTNAME 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51
UTC 2009 i686 GNU/Linux
- Windows XP Pro SP3 (fully patched to this date)
- Synergy Plus 1.3.4

ISSUE: Issue seems to occur when I lock my Windows box (Super+L) then move to my
Linux box and lock that one (Ctrl+Alt+L). After unlocking Linux and moving back to
Windows to unlock the issue becomes apparent.
WORKAROUND: Press Super + Ctrl + Alt a few times seems to correct the problem.

Setup #2
- Windows XP Pro SP2
- Windows XP Pro SP3
- Synergy Plus 1.3.4

ISSUE: It seems to happen after locking both machines and unlocking them. It shows
more often in the client side than the server side.

WORKAROUND: Same as above

I can provide a Wireshark if needed. The same thing happens when trying to run
Synergy through stunnel.

Google user: chad.den...@gmail.com

I collected the Debug1 logs for a pressing 'h' when it fails to press the character
and then again after clicking the taskbar and back into the text field (which always
enables me to type the previously locked out characters again).

Fails:
send enter to "CDENYAR-XP", 0,482 359 0000
hook: 0x00000048 0x00230001
hook: 0x06016848 0x00230001
hook: 0x07006848 0x00230001
event: Key char=104, vk=0x48, nagr=0, lParam=0x00230001
new mask: 0x0000
new mask: 0x0000
onKeyDown id=104 mask=0x0000 button=0x0023
send key down to "CDENYAR-XP" id=104, mask=0x0000, button=0x0023
hook: 0x00000048 0x80230001
hook: 0x06016848 0x80230001
hook: 0x07006848 0x80230001
event: Key char=104, vk=0x48, nagr=0, lParam=0x80230001
new mask: 0x0000
new mask: 0x0000
onKeyUp id=104 mask=0x0000 button=0x0023
send key up to "CDENYAR-XP" id=104, mask=0x0000, button=0x0023

Works:
event: button press button=1
onMouseDown id=1
send mouse down to "CDENYAR-XP" id=1
event: button release button=1
onMouseUp id=1
send mouse up to "CDENYAR-XP" id=1
hook: 0x00000048 0x00230001
hook: 0x06016848 0x00230001
hook: 0x07006848 0x00230001
event: Key char=104, vk=0x48, nagr=0, lParam=0x00230001
new mask: 0x0000
new mask: 0x0000
onKeyDown id=104 mask=0x0000 button=0x0023
send key down to "CDENYAR-XP" id=104, mask=0x0000, button=0x0023
hook: 0x00000048 0x80230001
hook: 0x06016848 0x80230001
hook: 0x07006848 0x80230001
event: Key char=104, vk=0x48, nagr=0, lParam=0x80230001
new mask: 0x0000
new mask: 0x0000
onKeyUp id=104 mask=0x0000 button=0x0023
send key up to "CDENYAR-XP" id=104, mask=0x0000, button=0x0023

Google user: rudeblunt

I have been using synergy+ 1.3.4 with the following setup:

Server: WinXP SP3 (fully patched) (synergys 1.3.4 - protocol version 1.3 -latest
windows installer)
Client: Ubuntu 9.10 (latest .deb) synergyc 1.3.4, protocol version 1.3

I can also reproduce the problem by locking/unlocking both displays, I also get some
random "stickyness" but I can't pinpoint the situations (and therefore reproduce)

(another 5 cents, just added this as there seemed to be no reports of this bug with
my setup)

Google user: jasonirwin73

I've seen the same behaviour as well (same setup as rudeblunt). The stickyness seems
to happen randomly and I have only noticed it affecting the server (Windows).
Pressing each meta-key seems to clear it.

Google user: cobryan

My behavior doesn't seem to be that modifier keys are stuck, but rather I can press
one key on a window, then that window loses focus and any other keypresses don't go
to that window. I have to shut down and restart synergy to make it work again. I
haven't been able to determine what gets focus when the current window loses focus. I
collected debug2 logs of pressing buttons when it works and doesn't work (tried
typing abcdef in a window. When it doesn't work, the window only gets the A before
losing focus), however the logs were identical so would not be helpful. Whatever is
going wrong isn't something that shows up in the log, and don't have any steps to
reproduce.

Google user: evilxhwnd

I am also experiencing this issue. Server on Mac OS X Snow Leopard and Client is
Ubuntu Jaunty.

Google user: kaydance

server: XP sp3
client: mac OSX Snow Leopard
issue:
sticky shift at random only on client machine. will see all caps when beginning
typing as well as mid sentence. to fix will have to hold or press shift key,
sometimes multiple times. if this does not correct issue the entire keyboard seems to
lock up and i'm unable to type anything on client machine. if this happens the only
way i've found to correct it is to reboot the client machine.

config:
section: screens
MAC:
halfDuplexNumLock = true
switchCorners = none
switchCornerSize = 0
PC:
halfDuplexNumLock = true
switchCorners = none
switchCornerSize = 0
end
section: links
MAC:
left(50,100) = PC(50,100)
PC:
right(0,50) = MAC(0,50)
end
section: options
keystroke(F7) = keyboardBroadcast(toggle)
end

Google user: nick.bolton.uk

Sticky/stuck meta keys (shift, ctrl, alt)

Google user: miles.bintz

I'm experiencing this problem as well.
SERVER IS FC8, Client is os-X.

As you can see, the problem can occur quite frequently. IT SEEMS TO HAVE NOTHING
TO DO WITH SCREEN CHANGES AS I've been in this window the entire time.
Furthermore, while pressing a meta-key will resolve the issue, sometimes it takes
multiple presses of varying duration in order for the client to register the key-up
event.

I don't think I experienced this until moving to Synergy+.

I tend to agree that this feels like a lost/delayed packet issue. Surely Synergy is using
TCP and not UDP for transport? Maybe it's time to break out ethereal....

(P.S. I wasn't yelling above. That was a stuck shift key ;) )

Google user: m...@halfzero.net

I've had the same problem. The frequency differs from day to day but it's certainly one
of the most frustrating things about S+, especially when I'm trying to focus on a project.
I've found the sure-fire way to stop it from happening is to hit the shift key on the
client. Server is Windows 7 64-bit, client is OS X 10.6.

Google user: bushwakko

Like commect 72, I have the exact same setup (linux server, osx client). I get the
exact same sticky shifts, that usually go away when clicking shift again. However
doing cmd/super+tab to fast (or letting them go simultaneously) seem to break worse.
then the thing I do it do cmd/super+tab a little slower (back and forth) and then it
works.

For me this has nothing to do with changing screens. This never happened with the old
synergy, started when I switched to synergy+. I'm using svn now, just hoping for some
fixes ;)

Google user: bushwakko

I made a separate bug for this:
"http://code.google.com/p/synergy-plus/issues/detail?id=334&q=meta&colspec=ID%%20Stars%%20Type%%20Status%%20Priority%%20Milestone%%20Owner%%20Summary#makechanges":http://code.google.com/p/synergy-plus/issues/detail?id=334&q=meta&colspec=ID%%20Stars%%20Type%%20Status%%20Priority%%20Milestone%%20Owner%%20Summary#makechanges

Google user: Jud.Stephenson

I want to note that when I have the issue, it seems as though there are some UTF-16
characters that are being inserted as input as the shift key is being held down.

I have a Vista x64 desktop as a server and an OSX 10.6 as a client. I find that when
programming (hitting the shift key quite a bit), there are instances when the shift
key seems to stick and trying to backspace the characters causes corrupt UTF-16 input
to be inserted.

I think this seems a little more interesting then just a "missed" KeyUp.

-Jud

Google user: majorh

I have this issue between OS X 10.6 (server) and Fedora 12 (client) with the latest synergy-plus. Does anyone
know any workarounds in the meantime?

If I bounce the synergy processes on each side, everything's back to normal until i flip between machines 2-3
times.

Google user: lstrout

I can reproduce this in 1 step using Synergy 1.3.1 (I'll try Synergy+ after I sleep):
server: WinXP client: Gentoo w/ Synergy 1.3.1 (I masked -r1 because it broke things)

Once the systems are up and synergy is running, on the server using firefox close a
tab using Ctrl-W

That's it. Going to the Gentoo client it would appear that the Win-Key is stuck.

Google user: lstrout

Holy cow... it even happens closing a tab with middle-click.

Google user: lstrout

Alright, so I tested with synergy+ 1.3.4 and it's the same. Also upgraded the
version of FF from 3.0.17 to 3.6 and get the same behavior. Also, it would seem
anything to do with tabs in FF kicks this off, change a tab, open/close, maybe
others. To top that off, now all I need to do is make FF the active window and
things stick.

Here's where it gets interesting. I use the Gentoo system to run nxclient, and when
the keys are sticky nx doesn't see it. Everything works normally there.

Google user: lstrout

After a fresh reboot of the Gentoo client none of the FF interaction kicks off sticky
key behavior. Curiouser and curiouser.

Google user: jason.e.reynolds

Still working on this - so buyer beware.

I am transitioning from Linux/Linux to OSX/OSX/Linux. While I did see the problem
occasionally, I saw it much more frequently when my Mac became the primary. The
break through came when I noticed that the stuck keys also happened on the linux
client. That points to server not client being to blame.

I've had some success with the following change. Note, it is somewhat a hack as
every key press is sent both a down & up, this might break games without additional
logic to enable/disable this fix.

COSXScreen::onKey(CGEventRef event)
else if (up) {

    //removed: if (!m_keyState->isKeyDown(button)) {  
        // up event for a dead key.  throw it away.  
    //removed:  return false;  
    //removed: }  

    m_keyState->onKey(button, false, mask);  
}  

// send key events  
for (COSXKeyState::CKeyIDs::const_iterator i = keys.begin();  
                        i != keys.end(); ++i) {  
    //change: 1) always set repeat false  
    //        2) send keyup right after keydown  
            // Note, might break some apps that need held keys -i.e games.  
            //    ideally detect and disable this change for those apps  

    m_keyState->sendKeyEvent(getEventTarget(), down, false,  
                        *i, sendMask, 1, button);  

    m_keyState->sendKeyEvent(getEventTarget(), up, false,  
                             *i, sendMask, 1, button);  
    }  
}  

Google user: chadmill

Here's a data point that may help. From linux-linux, when I pressed Alt-F1 as if to
switch to the first X port, the Ctrl key must have also been stuck, as it flipped out
of X and to virtual-terminal 1 instead. I don't know what that means, as to whether
the problem is in synergys or synergyc, but it might me useful to someone else.

server 1.3.1-6ubuntu1
client 1.3.1-6ubuntu1

Google user: chadmill

Wow, this will surely give insight to someone: One machine, using Alt-(number), flips
the other machine out of X (as if it's Ctrl-Alt-(number)), it can continue to flip
virtual terminals! That's outside of X! That should be impossible.

(Now, using the right software here. Both server and client: synergy-plus 1.3.4)

Google user: kbra...@kbranch.net

Alt+Fx alone is supposed to change between text mode consoles, ctrl is only required
when leaving an X instance. Make sure the ctrl key isn't stuck, open a terminal, type
in 'chvt 1', then try switching with just alt.

Google user: nick.bolton.uk

jason.e.reynolds - maybe you could attach an svn diff (.patch file)?

Google user: evilxhwnd

i have the same issue with the server running on linux and only one client on mac os
x 10.6. I would like to look into this, since it's been annoying me for months now.
However, i can't compile the client on mac os x from SVN since it fails.

Google user: chadmill

kbranch, I think you misunderstood what I was saying.

First: I don't think it should be possible to switch out of client X, from server X
at all. That I can is a weird manifestation of this bug.

Second: It is truly odd that once I am switched out of X, that new events pushed into
the X event queue (I presume this is how Synergy works) will operate on the console.
It should be immune to X events altogether.

Google user: kbra...@kbranch.net

Chadmill:

My understanding was that ctrl got stuck and let you change to a text console by just
hitting alt and an F key. That is definitely not supposed to happen, but it's at
least in the realm of possibility given that you're still in X when it happens.

Again, if I understand correctly, what happens next is that you continue to be able
to switch consoles by only hitting alt and an F key. This is the part I was saying
is the intended behavior and not a bug. From a text mode console, ctrl is not
required to switch to another console.

Google user: chadmill

kbranch, yes, you still misunderstand.

One machine (server) flips the other machine (client) out of X and continues to
manipulate the remote (client) machine.

As I understand it, from X on one server machine, I should not be able to switch
consoles on another machine (client), at least never after switching the client out of
X.

Google user: kbra...@kbranch.net

Ah, gotcha, sorry about that. That's definitely very odd. Trying to switch consoles on
a client just switches the server's console with my setup, does yours always act as
you've described, or only when you're able to switch due to a key being stuck? this
sticky keys bug has given me a lot of grief, but it's very intermittent for me, and I'm
not able to test with ctrl stuck down at the moment.

Google user: majorh

I'm not sure if this helps anyone else, but this fixed my sticky key issue between my Mac and Fedora box:

"http://rackerhacker.com/2010/03/03/sticky-shift-key-with-synergy-in-fedora-12/":http://rackerhacker.com/2010/03/03/sticky-shift-key-with-synergy-in-fedora-12/

Google user: The.Anonymous.Us3r

Thanks for the link, Majorh, but since I'm a Windows user, it didn't help.

My Shift keys also get stuck in much the same way as the person described in the link
from RackerHacker.com. The difference is I'm using 2 Windows Vista machines.

To summarize, when I'm on my client machine and use the Shift key to do something,
like capitalize letters, it consistently gets stuck. Regardless of whether it is the
right or left Shift key that was pressed. But, afterwards, when I hit the left Shift
key by itself, the problem goes away. This only happens when I hit the left Shift
key, not the right Shift key, even if using the right Shift key is what caused the
bug in the first place.

Less common (and less annoyingly) I sometimes get this problem on my server machine,
but this is extremely rare. As a result, I can't reliably reproduce this glitch on my
server machine, to which I am grateful, because I can live with it the way it is.
It's having to put up with this bug, nearly 100%% of the time on my client that is
aggravating.

I've been using Synergy 1.3.1 for years and this bug has been quite maddening. When I
learned of Synergy+ 1.3.4 a few weeks ago, I disabled ver 1.3.1, and eagerly setup
ver 1.3.4 on both my client and server machines, hoping that this problem would, at
long last, be resolved... but it was still there, just the way I left it.

This bug first appeared on my client/server Windows XP machines.
I'm currently using a client/server setup with Windows Vista Home Premium on both
machines running Synergy+ 1.3.4 and am still experiencing the same exact problem.

Google user: cvertz

This happens for me a lot. Sometimes it's Shift, Control, Alt, or even the Windows
(Super) key that sticks.

I use this macro, it might help someone:

keystroke(Control+Alt+z) = keyUp(Shift), keyUp(Control), keyUp(Alt), keyUp(Super)

Google user: jonathany70

Just to add another experience - I use all linux (Fedora 12 x86_64), and have been
experiencing sticky meta-keys since using synergy-plus (I previously used a local
compiled build of synergy with no issues). The issue is only manifested on the
"client". I have to tap the client meta keys to "unstick" them. never sure which key
it is.

Google user: jla...@gmail.com

I have a new Win7 installation (as synergy server) and had different Alt-Tabbing
problem (possibly Vista/Win7 specific one). The issue #6 has discussion about that and
a patch. Now after using this patched version for a little while, I feel it might have
helped also for this stickiness-problem. Although I'm not sure yet since sometimes the
stickiness just happened that often anyway.
"http://code.google.com/p/synergy-plus/issues/detail?id=66":http://code.google.com/p/synergy-plus/issues/detail?id=66

Google user: jason.e.reynolds

Re #82 / #86 - I do not recommend my previous patch for COSXScreen::onKey(). It
reduced the problem by maybe 50%%, but not enough to patch it into the main code.

I just posted a fix for a similar issue (OSX only, starting with 10.6.3) that is
showing real promise.
"http://code.google.com/p/synergy-plus/issues/detail?id=419":http://code.google.com/p/synergy-plus/issues/detail?id=419

Google user: filipbaran

I use Win7 as a server and Ubuntu 9.04 as a client. It appeared, that if server
version is 1.3.5 and client is 1.3.4: problem with sticky Alt seems to disappear. No
need to restart server or client, it just gone. I hope this observation will be
helpful for anybody.

Have been testing version 1.3.5 on both machines: Alt still stucks, but can be
released by tapping twice on Alt key (server side) or by moving cursor to the client
and back to server side.

Google user: john.ludlow.uk

You guys must have done something right because since upgrading to 1.3.5 the Alt key
has only stuck once (and that was fixed with the new Reset Server command).

Google user: filipbaran

According to my previous (98) comment and john.ludlow.uk: stuck Alt problems came
again from no reason suddenly. It doesn't matter what version is client or server. Now
I've got this problem for the whole time. Even resetting server (via the command)
didn't take effect.

I was too much self-confident in my previous comment. Now I have no idea on which side
is the problem. If someone of you guys can, please take some test. I will do it
either...

Google user: scp0801

I can confirm the same sticky key problem on Mac Clients with server running on
Windows 7. Alt, Shift, and Option don't work. For the following setup:

Win7: SynergyS
Two Mac OS X 10.6.3

Sticky keys don't work on Macs when running synergyc on them

synergy-plus-read-only from latest source,
--compiled as x64 in xCode, synergyc does not load at all
--compiled as 386 in xCode, sticky key problems

synergy-plus-1.3.5-rc-Darwin-i386.dmg
--synergyc has sticky key problems on Mac OS X versions 10.5 and 10.6

synergy 1.31.1, the problem does not exist

Some of the patches proposed seem to switch the apple key from Alt to Windows Start
key. Need to be consistent or provide an user configurable option for Mac clients.

Google user: jasonirwin73

I have just moved to 1.3.5 RC using Windows SPsp3 (server) and Ubuntu 10.04 (client).
I am seeing meta-keys randomly sticking/becoming activated even when not used on the
server. Whilst the problem did happen from time-to-time in 1.3.4, it was nowhere
near as severe as this (primarily the CTRL key, which causes all sorts of problems
when typing!).

The problem started as soon as the server went to 1.3.5.

Google user: shadowingfaith

I have a very similar problem. Mainly it's my shift key on my Ubuntu client. When I
move from WinXP SP2 Server to Ubuntu client, my shit key sticks and I can solve the
problem only br restarting the server process. Even this, however, doesn't fix it for
long. It will stick again in only a few minutes.

Google user: jasonirwin73

I have now reverted to 1.3.4 and the issue is still existing. After every key up on
the server (also back to 1.3.4) the CTRL key on the client become stuck. I am NOT
pressing the CTRL key!

Google user: guss77

I'm also having this issue - Ubuntu 9.10 server, Fedora 13 client and Ubuntu 10.04
client.
I had synergy+ 1.3.4 on Fedora and old synergy 1.3.1 on the Ubuntus. I had
intermittent stickiness problem on the Ubuntu client (but surprisingly not on the
server or the Fedora client).

The stickiness problem has gotten a bit worse in the last week but a new problem was
added, which I'm not sure is exactly a key stickiness issue: whenever I send an F key
from the server to the Ubuntu client, the Ubuntu client receives this as CTRL+ALT+F#.
As Linux is setup so that CTRL+ALT+F# changes a virtual terminal (and normally out of
the X graphics terminal) then you can see the problem. This happens regardless
whether CTRL and/or ALT are currently stuck for other keys - for example I can type
"c" in the terminal and it won't output as CTRL-C or ALT-C, but then pressing F1 will
switch to the first VT.

I've upgraded the Ubuntus to syerngy+ 1.3.5rc as downloaded from here, and that
caused the stickiness problem to become even worse - almost every key gets stuck
including letter keys, every time I use a meta key over the synergy connection it
gets immediately stuck Again - only in the Ubuntu client, the Fedora client running
synergy+ 1.3.4 and the server do not have issues.

I then downgraded to 1.3.4 as downloaded from here, and it went back to the previous
behavior - the Ubuntu client sometimes has CTRL or ALT stuck, but function keys
always send CTRL+ALT+F#.

Google user: trillex

My issue is that every time I have been on the other client (Windows 7 Home Premium),
the server (Windows 7 Ultimate) have sticky keys, most often it is ALT that is stuck
but it can be both shift, CTRL and ALT. I have to press these before the issue stops.

Both machines are using 1.3.5

Google user: pvdborch

Win XP server here, Ubuntu 10.04 client as well. Similar observation - after upgrade
to 10.04 synergy is absolutely unusable, ANY keypress instantly sticks the alt key
even if it wasn't even used. Shift is also an instant stick, haven't tested much
more, it's a disaster.

The reason I'm adding to this thread is that I've found that while the behavior
returns quickly, there is a short latency period where things work if I completely
uninstall and then install (not reinstall) synergy 1.3.1-6ubuntu1 on the ubuntu
client. Hope anything helps because this is really slowing down my productivity here.

Cheers
Philip

Google user: swieto...@gmail.com

And similar issues here. After connecting the first time I press ctrl client thinks
the ctrl is continuously pressed, so every after key I type later on is handled as it
was pressed with the control key.

I can easily press ctrl key on the client machine to fix it, but obviously that means
I can't use the server's keyboard only.

Configuration:
* server: Windows XP 64 bit, synergy+ 1.3.4
* client: Linux Fedora 12 64 bit, synergy+ 1.3.4

Google user: Ray.Woodcock

I fix a stuck Alt key in 32-bit WinXP Pro SP3 by playing a YouTube video in Firefox.
Any video. Just play one. Running WinXP Pro SP3 in VMware, I fix it by switching
out to Ubuntu and playing a YouTube video in Firefox there.

Google user: Termopeten

Same issue here on Ubuntu 9.11 server and Ubuntu 10.04 client, with synergy+ 1.3.4 on
both systems.

Hanging meta keys randomly on client side, sometimes it can be cured by pushing the
"infected" meta key on the server side, but not always. The only way to be sure to
cure the issue is to push all meta keys on client.

Is there a way to see if meta keys are hanging/held down on client computer - so at
least one can be warned when this happens, and maybe make it easier to find out what
trickers this event?

Google user: grugman

I've just come across this thread and have another interesting scenario to throw into the mix.

Is it possible there was a change to the X library's that caused this? I know that doesn't make sense for
Windows machines, but is it consistently a problem when a Linux machine is involved??

I say this because I have exactly the same problem (sticky Ctrl only released by client Ctrl press), but I'm not
actually using Synergy+. I'm using the Synergy 1.3.1 debs from Debian Lenny (1.3.1-5 released 2008-09-19
according to BTS) and have been since they were released, but this issue has only recently become a
problem.

Google user: karl.for...@gmail.com

Windows XP server and ubuntu 10.04 64 client: same problem with stocky meta keys.
Sometimes it works pretty well for hours, and sometimes it 's just unusable.
For me it is a very critical bug, and appeared only when I installed 10.04.
It was working flawlessly with previous ubuntu versions.
And I also noticed a correlation with the gnome screensaver.

Google user: BostonVaulter

Google user: nick.bolton.uk

? ?

Google user: david.pedowitz

Happens to me with Ubuntu 10.04 client and server. Right ALT key frequently gets 'stuck'

Google user: cuongkieunguyen

I have similar issue: typing on client looks like Caps Lock is held. Only pressing and releasing SHIFT on client helps.

OS X 10.6.3 server
Ubuntu 10.04 32 client
Synergy version: 1.3.4 (both)

Google user: Jud.Stephenson

Oddly enough, when I fixed the problem in bug #5, this problem went away.

Google user: Chris.Heinbokel

Reporting the same issue, with the Windows (super) key sticking. Issue presented in both Windows XP Professional and now, Windows 7 Ultimate (both x86) server-side.

It affects both the client and the server when the issue occurs, and like others have said, tapping the "infected" key resolves the issue temporarily.

Google user: bernd.kilga

Jud: Your binary doesn't fix the sticky keys, sorry. I'm still getting them.

Google user: pvdborch

Highly likely a problem with something Ubuntu 10.04 introduced. Same here, never any issues until upgrade to 10.04. My setup, as stated above, is Win XP server, ubuntu client.

WORKING WORKAROUND I've found though, which may help get to the bottom of this, is that changing the keyboard model in ubuntu from "Generic 105-key PC (intl)" to "Generic 104-key PC" results in reliably (one week now) no more stuck keys. Of course, this means that my German keyboard layout does not translate anymore and I have to type my ö's, ä's, ü's and ß's on the laptop keyboard.

As soon as I switch back to "Generic 105-key PC (intl)" stuck keys are back instantly.

Google user: markjreed

This is not sporadic as of Ubuntu 10.04 (client; server is Windows XP): it happens 100%% of the time. As soon as I press the control key on the server keyboard, the client gets stuck in control-mode. Pressing the control key on the client's own directly-attached keyboard reverts to normal, but only until the next time synergy sends a control-down. Pressing the control key on the server while it's stuck has no effect.

Google user: pvdborch

markjreed - do any of your keyboards contain non-English standard keyboard layouts? Since a non-international keyboard layout on the ubuntu machine fixes it for me this would be interesting to know. Same question for all other ubuntu users in here?

Google user: hamoid

I'm experiencing this bug all the time, and I am using OS X 10.6.3 server, Ubuntu 10.04 client, both are German keyboards (physical) but both OSes using an international Spanish layout.

But I just read comment 120 and now it's fixed! The problem was that I had selected "Apple keyboard" in System > Preferences > Keyboard > Layout > Keyboard model in Ubuntu. When I switch to "Generic 104-key PC" it's working perfectly, including áéíóúñ. What a relief. Even my mouse clicks were going crazy (files being copied on drag, web pages opened in new windows...).

Google user: pvdborch

hamoid - glad my suggestion worked for you, especially because it stopped working for me today. This is so frustrating. I've played with a dozen keyboard layouts, the Shift, Ctrl and Alt keys get stuck every time now.

Looks like Synergy Plus has gone the way of the original Synergy - no more development?

Has anybody found a working alternative?

Google user: sven.rieke

Great, the workaround from comment 120 works for me!!!!

Had to change the keyboard layout on the server machine to "Generic 104-key PC", and now my Alt key is released always on the client machine.

Both machines use Ubuntu 10.4

Google user: sven.rieke

Well, well, well, the workaround worked at least half an hour, since then I've the same problem again.
Even resetting both machines doesn't work.
This is hopeless.

Google user: dwangoac

This is really killing me after upgrading my two Linux systems to Ubuntu 10.04. This may or may not help but in my case I'm using xmodmap in my ~/.bashrc file to clear capslock and make the capslock key map to escape (which indelibly brands me as a vim user but I digress). When a key is stuck and xmodmap starts it says "Please release the following key within x seconds" and states the key that is held down. This has come in really handy for knowing which key to toggle but unfortunately two "UNKNOWN KEY" keys keep getting held down in amongst right control and other keys. I have yet to figure out which unknown keys these are and my only option is to restart X or the system when this happens.

I'm currently restarting multiple times a day and it's becoming a significant productivity drain. I feel really helpless as nothing I've tried has made any impact on the problem. Nick, we appreciate your work on this - if there's any specific testing we can do please let us, the community, know. Thanks!

A.C.

Google user: maulkin

Just tried with the latest head build from subversion, the issue still appears.

To confirm, it will be cleared by using the key on the client machine.

-dDEBUG2 log attached

Google user: karl.for...@gmail.com

Same for me: I have to reboot multiple times per day and it's getting really really
anti-productive.
Sometimes I have to press the CTRL key on the other (unbuntu-attached keyboard) to release the key, but it starts again to mess one minute later.

Google user: dwangoac

If I could figure out what key to press I'd be in a far better boat but all I get for a hint is:

xmodmap: please release the following keys within 2 seconds:
UNNAMED (keysym 0x0, keycode 206)
UNNAMED (keysym 0x0, keycode 207)

I'm going to see if I can hunt down what keys those are as I'm assuming if I can hit them I'll be able to clear the problem but in the meantime I have no recourse but to reboot the system or restart X.

Any suggestions would be very helpful.

A.C.

synergy2.log - 27 Aug 2010 23:33

Google user: EliFlesher

If you're experiencing the problem where it is just your shift key getting very aggressively stuck down (Issue #2 ), I have posted a solution there.

Google user: ben.m.dowling

I'm experiencing the same problem with Ubuntu 10.4 as both the server and client. I also have my caps lock key bound to escape, but I don't think that's the issue. Shift, Ctrl and Alt all seem to get stuck, and EliFlesher's suggested fix in (issue #2 ) isn't working for me.

Changing to a 104 layout keyboard did initially solve the problem, but it seems to be back for good!

Google user: dwangoac

The fic for Issue #2 did not help me either, unfortunately. My original situation was that unnamed keys were being held down which I couldn't clear requiring multiple reboots a day. That was completely unusable so I eventually managed to sort out that creating an xmodmap file including:

keycode 206 =
keycode 207 =

and loading it in .bashrc by calling xmodmap prevents the unnamed keys from being depressed. I still get shift, both control keys, both super keys, etc. stuck all the time but at least I can clear those by hitting them. As noted having xmodmap in .bashrc puts up messages about which keys are held down so if I discover that something's behaving strangely I open a terminal and figure out which keys are stuck. It's a nasty workaround but having Synergy is still worth the cost.

I wish there were a way to track down the source of this problem... If there's any testing I can do to help please let me know. Thanks!

A.C.

Google user: death2artists

I am having the same problem with windows xp sp2 as the client and windows 7 as the server. Figured I would add this, since the last few comments have been about something changing in ubuntu to make this happen.

I have this problem once every half hour or so, and it is really irritating, because I will have half a sentence written before I realize that it has popped up a bunch random windows.

Google user: vicariousdm

I am also experiencing this problem between two Linux boxes (my desktop and a Thinkpad T400). Both are using KDE4 (4.5 on the desktop, 4.4 on the laptop).

At first I thought this was an issue with KDE4 on the laptop, since sometimes kglobalaccel would freak out and render my keyboard useless for a while (from a few seconds to a few minutes), all this while using 100%% CPU. But then I noticed the behaviour with the meta keys.

While writing this, I have went back to Synergy-1.3.1 (not Synergy+) and also tried x2x, and sadly I experience a similar behaviour with all of them. I should test these with other WMs such as Fluxbox, though I believe the WM should not matter here.

It's too bad to see such a fine piece of software suffering such a showstopper bug. I had to resort back to using the laptop's keyboard and touchpad (since this is the laptop from work and I cannot afford to be restarting X server or experiencing crazy behaviour while working). But nevertheless I would love Synergy+ getting rid of this bug (heck, I would even pay for it, no questions asked).

Please let us know what can we do in order to get this fixed.

Juan Manuel

Seems that my last comment on the Google-code issue did not get imported. As follows:

That's odd, I swear I saw a post here a few days ago by somebody stating that this was a Xorg bug and that he experienced this on Lucid without using Synergy.

While I don't know about this being a Xorg bug, I do remember not having this problems when I used Synergy for the first time ~1 year ago (and that was with Xorg server 1.5 or 1.6, not 1.7 as I have now). And it does make sense since I was able to trigger this bug on Synergy+, X2X and also on the old Synergy.

A quick google search turned up this: https://bugs.launchpad.net/xorg-server/+bug/536715. I found another similar one for Debian, dated 2008

While the symptoms may not be exactly the same, I believe they are indeed related.

PS: congratulations both for the migration to Redmine and for merging efforts with original Synergy! It's good to see that FOSS is taken through the nicer and better path :)

Juan Manuel Santos wrote:

Seems that my last comment on the Google-code issue did not get imported. As follows:

Ah sorry about that, looks like you posted just before I closed the old issue tracker.

PS: congratulations both for the migration to Redmine and for merging efforts with original Synergy! It's good to see that FOSS is taken through the nicer and better path :)

Thanks for the congrats, I'm glad the effort was worth it. Thanks for using Synergy.

Just to update, I took a look at the duplicates for this bug, specially bug #441. At the end of the comments, someone mentioned that starting synergy from inside Gnome's "startup sytem" fixed the issue. I did so under KDE-4.4 for the client (which is the one experiencing meta keys stuck, never the server). It seemed to work for a while, but after a few back and forths, eventually some meta keys started to get stuck.

It is important to point out that this seems to be completely randomic. Sometimes it may happen on first switch to client screen, sometimes after the 10th switch, and sometimes after the 100th. But eventually, it happens :(.

Maybe we could have better luck by reporting it upstream to Xorg devs?

Juan Manuel Santos wrote:

Maybe we could have better luck by reporting it upstream to Xorg devs?

Unfortunately, as death2artists points out this is not limited to Linux as he sees this "with windows xp sp2 as the client and windows 7 as the server."

I've been watching the pattern of this for the last couple of months as I rely on Synergy so heavily that it's worth the cost to trudge through the painful points. There's definitely a "pattern" - as these events happen in storms. When the weather's bad (theoretically speaking) I see keys being held down on nearly every transition. When the weather is good I can go days without ever seeing a key get stuck, sometimes lulling me into a false delusion that the issue has magically disappeared.

Removing the key association using xmodmap prevents the given key from being held down so I know that it's the fault of the server, or more specifically the interaction between the server and the client. My best suspicion is that there's a timing problem that goes in and out of sync. This ticket is very appropriately listed as an urgent issue as I suspect many individuals have encountered the problem and not posted about it.

Nick, as always you have my testing support; I am a beta tester by trade and I'm immanently willing to help track this problem down. Thanks again for your interest in resolving these issues.

A.C.

Yeah, sounds very much like a race condition now that you mention it. Of course the devs have my testing support too :)

I'm running into this issue as well, except for me it's happening with the Windows key. My setup is as follows:

Server: Windows 7 Enterprise x64 (Synergy+ 1.4.1 x86 Beta & OpenSSH via CYGWIN)
Client: MacBook Pro OS X 10.6.4 (SynergyKM 1.0 Beta 7 connecting via SSH tunnel)

Everything works perfectly on the Mac. However, when I return the mouse to the Windows server 90%% of the time I have to press the Windows key in order to highlight text and drag-and-drop. This is tested running with the SSH tunnel both on and off. Same problem.

I'm also experiencing this issue... but it's not just the meta keys; occasionally a typing key will get stuck as well (letters, spacebar, the Home key on one occasion). In this case, just hitting the backspace key seems to be enough to unstick the typing key (but does not unstick the meta keys). The issue seems to occur only when the mouse pointer is on the client display.

The suggested method of unsticking the meta keys (depressing them one by one) does NOT work for me; I actually have to switch over to the client machine via KVM and then depress the keys one by one to get them to unstick.

I was experiencing this issue occasionally (perhaps once per day or less, on average) with 32-bit Windows XP SP3 as the server, and 32-bit Debian Unstable as the client; after switching the client to 64-bit Ubuntu 10.04.1, I experienced a marked increase in frequency (several times per hour, on bad days).

Jeff Lee wrote:

occasionally a typing key will get stuck as well (letters, spacebar, the Home key on one occasion). In this case, just hitting the backspace key seems to be enough to unstick the typing key... I actually have to switch over to the client machine via KVM and then depress the keys one by one to get them to unstick.

I've started noticing that regular keys get stuck too (it's been the w key a lot) - I didn't know about the backspace method but I'll give that a shot. I've also recently found that sometimes keys get stuck so badly that I have to switch to the client's keyboard to depress keys but sometimes even that isn't enough - the "weather" has been very bad today with stuck keys every few minutes and now I'm seeing "UNNAMED (keysym 0x0, keycode 204)" being held down which I have my xmodmap pointing to "keycode 204 = NoSymbol AltL NoSymbol AltL NoSymbol Alt_L" and yet Left-Alt wasn't clearing the stuck key. I will yet again be forced to restart X to resolve the problem which is highly disruptive.

Will no one come to our aid? As always, if there is anything, ANYTHING, I can do to assist in investigating this issue or regressing a fix please let me know. Nick, we beseech thee for help!

A.C.
******

P.S. - I had to hack my signature with @ characters on either side to get it to not turn into a linebreak... :)

This bug will not be fixed in version 1.x by the Synergy team (but patches are welcome). Version 2.0 will be designed as to prevent this from happening.

? ?

Nick Bolton wrote:

This bug will not be fixed in version 1.x by the Synergy team (but patches are welcome). Version 2.0 will be designed as to prevent this from happening.

Hi Nick - thank you very much for looking in to this ticket. I realize that it is a very difficult problem to solve but it looks like 2.0 is scheduled a long way out with many releases between then and now. Can you give a bit of flavor of when you expect 2.0 to be in an alpha or beta state? The implication of your note is that 2.0 will be a complete rewrite which always raises a red flag for me (GRUB2 and KDE 4.0 come to mind).

This problem is so bad for me on some days that if it will be an extended period of time before there is any hope of resolving this problem I may try successively older versions of synergy in the hope that I might be able to find a point where this bug doesn't exist. My desperation comes from the fact that I depend on Synergy heavily for the productivity boost I gain but on an average day like today I've already had to unstick keys over two dozen times and I've even resorted to restarting both the client AND the server which does seem to help.

If there were a commitment to fix this issue near-term I and several others would likely be very interested in donating to the cause - in my case, both through testing and financially. I see this as a must-fix issue that should not be deferred but I respect the difficulty in fixing it - if it were easy I'd have fixed it myself by now if I had the capability. :)

Thanks again for your time and understanding and I look forward to any information you can provide on a timeline for the fix. Good luck,

A.C.

I've done some testing over the last week and I've confirmed (after many hopeful-looking days) that the sticky keys problem existed at least as far back as Synergy 1.2.2. It took four days to manifest itself and I almost declared victory but I've had four stuck keys situations today, usually after touching a meta key on the client. I'll go back further if I can manage it - I have an Ubuntu 10.04 server, an Ubuntu 10.04 client, and a Windows XP SP3 client so hopefully I can keep going backward in my testing. If anyone else tries this take note that you may need to hunt down the libstdc++2.10-glibc2.22.95.4-27i386.deb package for older versions of Synergy.

Nick, I'm going to keep going backward in tracing this issue. This continues to be a must fix for me and I'll continue to contribute in whatever way I can to see this issue resolved. I'd still appreciate an update on when you believe this will be resolved (i.e. when version 2.0 will be released based on the current status of this ticket). Thanks for your time,

A.C.

Update: Synergy 1.2.2 has been far less likely to have sticky keys than Synergy+ 1.3.5 was but it does still have stuck keys every once in a while. I tried going further back to 1.0.14 but that build aborts as soon as an Ubuntu client attempts to connect so I've been unable to obtain any further data on the issue.

For now I'm going to stay all the way back on 1.2.2 released in 2005 as at least this way I can Get Stuff Done (TM). I am still available to assist in whatever manner I can, whether that's verifying a patch or performing alpha or beta testing for the purported 2.0.0 release of Synergy.

Best of luck Nick and team,

A.C.
******

I've had great luck overcoming this issue using the fakeAllKeysUp hack suggested in comment #58 by crazygeorge:
http://synergy-foss.org/pm/issues/19#note-58
(originally at http://code.google.com/p/synergy-plus/issues/detail?id=9#c58 )

This is on my client and server both running Ubuntu 10.10; the problem didn't seem as frequent on previous Ubuntu versions, but I've experienced similar issues in the past that seemed to come and go with kernel updates. I tried the hack after numerous other attempts failed to solve the problem.

With that hack, the stuck keys become a minor annoyance; you just bash some keys on the server's keyboard and it stops. Previously, this was a show stopper -- if a key got stuck, there seemed to be nothing I could do to un-stick it, including bashing keys on the client's physical keyboard and killing synergy. The client would just have a stuck modifier key (usually alt, ctrl, shift, or super) until I restarted X. This got so bad I actually stopped using one of my computers, so I wouldn't have to give up and log out multiple times per day.

Thank you, crazygeorge! I certainly look forward to this bug being solved "the right way" in Synergy 2, but in the mean time, I think it would be great if the package maintainers could consider incorporating the fakeAllKeysUp hack. It would probably help a lot of people. If I weren't so addicted to using synergy I'd have given up!

I've noticed this problem seems to be exacerbated when running X-based apps in X11.app on OS X (in my setup, my Mac is a synergy client of my Win7 synergy server). I find myself doing the modifier key sonata allegro quite often when I'm running Inkscape for example, even if OS X retains focus between key-commands.

Is there any update on a possible fix for this? It is driving me ABSOLUTELY NUTS....

M B wrote:

Is there any update on a possible fix for this? It is driving me ABSOLUTELY NUTS....

I should have updated a couple of weeks ago but it turns out I was wrong about Synergy 1.2.2. When all clients and the server are running Synergy 1.2.2 I do NOT encounter any stuck keys at all. There are some other issues with this older Synergy build but I have not once seen a stuck key in the last several weeks of testing. The result I reported above turned out to be caused by a newer, mismatched client.

With this information available it is possible for myself or someone else to narrow in on the point at which this problem started - in other words, the next step after having someone else confirm that the problem is not present in Synergy 1.2.2 is to halve the problem domain (pick a build halfway between build 1.2.2 and the most recent build released) and determine if the problem exists there then repeat the process until the build where the error was introduced is located. This will not fix the problem but will go a long way toward helping a qualified developer determine the source of the problem.

In my case it takes about a week per build to be absolutely sure there are no stuck keys. YMMV so if you have a faster reproduction method please feel free to test and post here.

Again, please accept my apologies for not getting back to this earlier. Best of luck,

A.C.
******

This is happening to me, too.

Server is Synergy 1.3.1 on Windows 7 (desktop). I'm not sure what version of Synergy the client (Mac OSX 10.6, laptop) is running, but it was downloaded/installed at the same time as Synergy on the server, so it should be 1.3.something.

I'll be typing on the client and the Shift or Alt key will get stuck. That causes random caps when typing, and the alt key causes mouse issues in Adobe programs.

Ooh. I just updated my Windows Synergy server to the beta 1.4.1 and performance has increased dramatically. My mouse was laggy before too, but it's much smoother now, and no sticky keys yet.

Elaine VDW wrote:

Ooh. I just updated my Windows Synergy server to the beta 1.4.1 and performance has increased dramatically. My mouse was laggy before too, but it's much smoother now, and no sticky keys yet.

Sorry for posting three times in a row... but I'm still getting sticky keys after all! Overall performance does seem better with the beta, though.

Bug Task

Sticky/stuck meta keys (shift, ctrl, alt) Ensure sticky meta keys (shift, ctrl, alt) does not occur

1.3.1

Various

Ensure sticky meta keys (shift, ctrl, alt) does not occur Ensure sticky modifier keys (shift, ctrl, alt) does not occur

Urgent Normal

Nick, I appreciate that you've updated this issue but I respectfully disagree with the drop in priority. By all accounts this is the most active and disruptive problem in the list and has no viable workaround outside of downgrading to older versions which is not a viable option for users of certain newer operating systems.

I continue to be dedicated to the resolution of this issue. I've recently determined that the problem does not appear to be present in build 1.2.6 (or earlier) but we know the problem was definitely present by build 1.3.1; my next move is to try 1.3.0 and continue to narrow down where the problem was introduced. Once I've found the build the issue was introduced in I'll attempt to build from source and narrow in on the exact change. As mentioned this takes about a week per test to avoid false positives so any assistance from others would be greatly appreciated (in particular it would be helpful if someone tested 1.2.7 while I work on 1.3.0).

Thanks,

A.C.
******

Does the update of the subject mean something has been committed concerning this issue?

Florent Bruneau wrote:

Does the update of the subject mean something has been committed concerning this issue?

Apparently not - the most recent update was:

Nick Bolton wrote:

This bug will not be fixed in version 1.x by the Synergy team (but patches are welcome). Version 2.0 will be designed as to prevent this from happening.

I am not a developer outside of copy-and-paste as far as C code is concerned so the best I can hope to do is isolate where the failure happened. I've had good results with build 1.3.0 so far but I can't definitively declare that it was not present in that build without few more days of testing under my belt. Luckily there aren't too many changes between 1.3.0 and 1.3.1 so I'm hoping to narrow in on the culprit within the next few weeks.

Thanks for checking in on this one,

A.C.
******

Update - I just got a series of stuck modifier keys with build 1.3.0 which means the issue lies somewhere between release 1.2.6 and 1.3.0. I'll try 1.2.7 and take it from there. If someone would like to confirm that the issue doesn't happen for them on 1.2.6 I'd appreciate it as there's always the possibility I just didn't encounter the problem in 1.2.6 and it actually existed there anyway.

Thanks to all for reading my frequent updates today,

A.C.
******

h3. My list of priorities

1. Finish the spec for version 2 (95%% done)
2. Release 1.3.6 (40%% done)
3. Release 1.4.2 (75%% done)
4. Start writing 2.0.0

h3. The rationale for version 2

Synergy needs rewriting from scratch in order to provide a long term fix for bugs such as the "sticky keys" issue. It is difficult to fix bugs in the current version of Synergy without causing regressions, which is why there are so few contributors - people are almost scared of breaking the software. With this rewrite, we will use the Scrum methodology (with integration testing) in order to make the software more robust, and easier for the community to maintain. The software will still look and feel almost exactly the same to the end-user (support for v1 configs, seamless usage, simple gui, etc), it'll just be easier to work on for the devs.

Nick, thank you very much for taking the time to clarify your priorities and your plans for future builds. This isn't the first project to undergo a rewrite - there's an interesting list of other projects that have done this highlighted in the talk notes at http://greenfly.net/talks/misc/grub2.html.

I'm hitting the jackpot today as it took a mere 10 minutes to reproduce the stuck keys problem on build 1.2.7 and thus my testing so far indicates that the issue lies between builds 1.2.6 and 1.2.7. One note of interest is that I started playing music with mpg123 in one of my Ubuntu 10.04 client systems when the stuck keys started happening in both 1.3.0 and 1.2.7 which may just be coincidental but might also be a clue.

My next challenge is getting 1.2.6 to compile from source as the next step of isolating the exact change requires it. Unfortunately it looks like it may be a bit of a daunting task as some of the libraries required are no longer available on modern distributions and worse yet it looks like there were a significant number of changes that were lost in the repository per the following change:
http://synergy2.svn.sourceforge.net/viewvc/synergy2?view=revision&revision=873

I'll do what I can to narrow in on the problem and coordinate a patch but it's looking to be a bit difficult...

Thanks again Nick,

A.C.
******

This isn't really the place to discuss whether or not version 2 is a good idea. Please post on the mailing list if you have any thoughts.

I have updated to build 1.3.6 and I have confirmed the stuck keys issue is still present in that build as expected (I reproduced the problem within an hour of updating and had no other applications outside of a terminal prompt and an E-Mail client running at the time).

I've confirmed that this issue was introduced between builds 1.2.6 and 1.2.7. Unfortunately, I have been unable determine which change introduced the problem due to two major problems. First, the SourceForge SVN repository has no history of committed checkins for that period meaning it's almost impossible to know what actually changed as the only history is the ChangeLog change descriptions. Second, I have been unable to build anything from source in Ubuntu 10.04 due to the error "CArchDaemonUnix.cpp:53: error: ‘exit’ was not declared in this scope"; a Google search shows others have encountered this error but no solution has been posted.

Nick, best of luck on your efforts and let me know if I can be of assistance testing the 2.0 branch once it's ready for alpha testing. Thanks!

A.C.

If this can help.

I personnally fixed the issue for my use case by compiling synergyc without support for XDB extensions. AFAICT, this only breaks the modifier remapping.

Florent Bruneau wrote:

I personnally fixed the issue for my use case by compiling synergyc without support for XDB extensions. AFAICT, this only breaks the modifier remapping.

That's a very interesting potential solution - can you elaborate on what you did to disable that support? I don't see an XDB extension in the old 1.2.6 source but I do see references to an XKB extension. I'm pulling the latest source code now to poke around and see if I can sort out what to do on my own but I appreciate any help you can offer.

Thanks!

A.C.
******
(I keep forgetting to add @ around my signature :)

Florent, can you confirm which extension you disabled and how you did it? I've attempted to disable the XKB extension in CMake but I can't quite figure out how to do it properly (disabling it in the resulting config.h file generated after running ./hm.sh conf does not work and removing references from line 132 of CMakeLists_config.txt doesn't help either). I was able to successfully compile SVN revision 877 (matching release 1.3.6) without any extensions disabled but encountered stuck keys within minutes.

Please feel free to tell me to RTFM but I honestly haven't found a clear answer on how to disable this kind of extension even after researching it.

Thanks in advance for any pointers on what to do here,

A.C.
******

Allan Cecil wrote:

Florent, can you confirm which extension you disabled and how you did it? I've attempted to disable the XKB extension in CMake but I can't quite figure out how to do it properly (disabling it in the resulting config.h file generated after running ./hm.sh conf does not work and removing references from line 132 of CMakeLists_config.txt doesn't help either). I was able to successfully compile SVN revision 877 (matching release 1.3.6) without any extensions disabled but encountered stuck keys within minutes.

Hi Allan, here is the procedure I followed:
* checkout the synergy
* compile it using cmake
* hack the generated file "config.h" by changing the line @#define HAVEXKBEXTENSION 1@ to @#define HAVEXKBEXTENSION 0@.
* cd bin/debug && make

I'm sure there is a better solution (by passing an argument to cmake).

Hi Florent,

I had actually tried that method myself last week (of altering config.h to setting HAVEXKBEXTENSION to 0 and recompiling with make) but I ran into stuck keys. I checked the source out from scratch today and tried it again but got stuck keys within an hour of testing with two Ubuntu 10.04 systems.

I'm not sure how to confirm after the fact that the XKB extension has been compiled out but at least for me I was unable to duplicate your success. If you have any other thoughts or suggestions I'd love to hear them.

Florent Bruneau wrote:

I'm sure there is a better solution (by passing an argument to cmake).

I'm sure there's a better solution too but I couldn't sort it out even after hours of playing with it.

Thanks again for taking the time to get back to me on what you did,

A.C.
******

Allan Cecil wrote:

I had actually tried that method myself last week (of altering config.h to setting HAVEXKBEXTENSION to 0 and recompiling with make) but I ran into stuck keys. I checked the source out from scratch today and tried it again but got stuck keys within an hour of testing with two Ubuntu 10.04 systems.

Please, note that the @cd bin/debug@ is an important step in the procedure; running @make@ in the root directory regenerates @config.h@ and thus makes the edition of @config.h@ useless (I ran into that issue the first time I tried).

Florent Bruneau wrote:

Please, note that the @cd bin/debug@ is an important step in the procedure; running @make@ in the root directory regenerates @config.h@ and thus makes the edition of @config.h@ useless (I ran into that issue the first time I tried).

I copied your command and executed @cd bin/debug && make@ after editing the config.h file but for whatever reason the config.h file was indeed reverted when I did that - thanks for thinking about that. I altered config.h a second time and did the @cd bin/debug@ as the first command then make as the second and I finally got a different result. Here's what I see now during when running make in bin/debug:

/home/user/synergy-read-only/lib/platform/CXWindowsKeyState.cpp: In static

member function ‘static void CXWindowsKeyState::remapKeyModifiers(KeyID,

SInt32, CKeyMap::KeyItem&, void*)’:

/home/user/synergy-read-only/lib/platform/CXWindowsKeyState.cpp:752:

error: ‘XkbBuildCoreState’ was not declared in this scope

make[2]: *** [CMakeFiles/synergy.dir/lib/platform/CXWindowsKeyState.o] Error 1

make[1]: *** [CMakeFiles/synergy.dir/all] Error 2

make: *** [all] Error 2

I'm at SVN rev 902 so perhaps the answer is to go back to 877 (matching 1.3.6) or even further but I suspect I'm still missing a step outside of just setting HAVEXKBEXTENSION to 0. Did you have to make any other changes to compile or do you have any other suggestions?

Thanks again!

A.C.
******

Allan Cecil wrote:

Florent Bruneau wrote:

Please, note that the @cd bin/debug@ is an important step in the procedure; running @make@ in the root directory regenerates @config.h@ and thus makes the edition of @config.h@ useless (I ran into that issue the first time I tried).

I copied your command and executed @cd bin/debug && make@ after editing the config.h file but for whatever reason the config.h file was indeed reverted when I did that - thanks for thinking about that. I altered config.h a second time and did the @cd bin/debug@ as the first command then make as the second and I finally got a different result. Here's what I see now during when running make in bin/debug:

[...]

I'm at SVN rev 902 so perhaps the answer is to go back to 877 (matching 1.3.6) or even further but I suspect I'm still missing a step outside of just setting HAVEXKBEXTENSION to 0. Did you have to make any other changes to compile or do you have any other suggestions?

Oops, I forgot I had to make a small patch for that one:

--- a/lib/platform/CXWindowsKeyState.cpp

+++ b/lib/platform/CXWindowsKeyState.cpp

@@ -747,11 +747,13 @@ void

 CXWindowsKeyState::remapKeyModifiers(KeyID id, SInt32 group,

                            CKeyMap::KeyItem& item, void* vself)

 {

+#if HAVEXKBEXTENSION

    CXWindowsKeyState* self = reinterpretcast<CXWindowsKeyState*>(vself);

    item.mrequired  =

        self->mapModifiersFromX(XkbBuildCoreState(item.mrequired, group));

    item.msensitive =

        self->mapModifiersFromX(XkbBuildCoreState(item.m_sensitive, group));

+#endif

 }  


bool

Thanks - this allowed me to compile as expected. Unfortunately about 6 hours after starting to use the build I had both meta / super keys get stuck on me (which is 5 hours better than any previous attempt with the current codebase; only time will tell if it's a bearable rate of failure). I'll attempt to verify that XKB has really been disabled and I'll do some additional testing to see if the frequency of stuck keys is lower than it was before.

I've been triggering a lot of updates to this ticket so I'll try to hold off on bumping / updating it until I have useful testing results to report. Thanks again,

A.C.

For the last two weeks or so I've successfully used build 1.3.6 even in Windows 7 64-bit which I did not think was possible (Ubuntu 10.04 server, Ubuntu 10.04 client, Windows 7 x64 client with UAE disabled). There are a few issues with that old build but I haven't had any stuck keys at all which has been wonderful. Florent's solution sounds like it should have worked and perhaps I'll try compiling again at some point but for now I'm going to continue to go with the workaround of using the older build that doesn't include the problem. I do wish I could compile to find the change that introduced the problem but without any source code change control from that period outside of the ChangeLog that's a nearly impossible task.

I hope this workaround is helpful to others but I know it doesn't solve the problem so please keep me on the alpha tester list for the 2.0 branch. Thanks!

A.C.
******

Ensure sticky modifier keys (shift, ctrl, alt) does not occur Prevent sticky modifier/meta keys (shift, ctrl, alt)

Prevent sticky modifier/meta keys (shift, ctrl, alt) Sticky modifier/meta keys (shift, ctrl, alt)

Client and server are both running Ubuntu 11.04 with xorg-edgers and the kernel mainline kernel-ppa PPAs. Recently this problem has gotten so bad for me that I can reproduce it very easily. Once the client and server connect to each other, everything works fine the first time I go from a server to a client, if I come back to the server everything still works fine, but as soon as I go back to the client, it starts behaving as if control is held down constantly (pressing "v" pastes, pressing "h" does backspace, etc.). Finally, when I'm on the server there are never any problems no matter what the state of the problems on the client. I can reproduce the problem just by starting synergy, going to the client, going back to the server, and going back to the client, all without pressing any keys, and on the second visit to the client, the problem is happening.

Actually, I was wrong, the working machine, the server, was running xorg-edgers and kernel-ppa, but the broken one, the client, wasn't. Once I upgraded the client, the problem went away. So maybe there's a fix in xorg?

Another data point. I just migrated the client to amd64/X86_64 while the server is still on i386/32bit and the problem has resurfaced. Both machines are still on the same versions of xorg and kernel, just different architecture.

So is there something in binary differences, versions or architectures, that might change what goes over the "wire"?

Scratch all my previous comments and supposed data points. :-)

The culprit was actually a USB keyboard. The client is a laptop with its own keyboard. If I boot it up without the USB keyboard (a Microsoft Natural Keyboard Pro) plugged in synergy works just fine for any combinations of starts, stops, screen switches, and post-boot USB keyboard connections and disconnections. If, however, I boot the client up with the keyboard plugged in from boot, I can reproduce the problem regardless of starts, stops, screen switches, and post-boot USB keyboard connections and disconnections. IOW, when the machine boots up with the USB keyboard plugged in, it doesn't matter what I do, the problem will recur, until I reboot without the keyboard plugged in.

This is a little strange since the client is a laptop so it already has another keyboard of it's own. Is 2 physical keyboards a magical number that messes up synergy or is it that the keyboard is a USB keyboard?

Ok, maybe that's not it either. I just had one boot without the USB keyboard attached where the problem was occurring. So the problem may just be intermittent. At least I've confirmed that it's a per-boot phenomenon.

Ross Patterson wrote:

Ok, maybe that's not it either. I just had one boot without the USB keyboard attached where the problem was occurring. So the problem may just be intermittent. At least I've confirmed that it's a per-boot phenomenon.

I'm glad you've somewhat narrowed it down in your situation - thanks for posting your experience. I can tell you that I have easily spent 50 to 60 hours on this problem trying to find some rhyme or reason and to be honest I finally concluded that it might as well be atmospheric interference or cosmic rays for how difficult it is to narrow down. The only way to know for sure that you've licked it is to go an entire week or more without any problems at all. This problem offers so much false hope.

The good news is that development of Synergy 2 seems to be progressing although there is still a fair amount of work to be done from what I can tell. I am still happily using Synergy 1.2.6 and enjoying sticky-less synergy usage but I admit that 1.2.6 has a few of its own unique characteristics such as losing the mouse pointer for 5 to 7 seconds at a time. With that said the cure is way better than the cold and I've even managed to get 1.2.6 to work well in Windows 7 so long as UAC is disabled.

Anyway, best of luck in your specific scenario and post if you find something interesting,

A.C.
******

Guys, I appreciate that you are keen to help us solve this issue. However, long comments describing the same problem over and over are not helpful to us developers. Please use the user mailing list instead for this sort of discussion, and make sure you continue an existing thread:

http://groups.google.com/group/synergy-plus/browsethread/thread/f3d824408c73f07c
http://groups.google.com/group/synergy-plus-dev/browsethread/thread/2ca77339bddf778e?fwc=1

I'm very sorry to tell you this, but you are actually doing more harm than good with your discussion. This number of non-technical messages dilutes important information, since there is now so much info to wade through, the thread becomes useless. As a result of many "me too" messages, I have un-watched this bug report.

If you do really have any real technical details to add to this issue, make sure your comments are concise (keep it to just a few words if possible).

Shouldn't this bug have highest priority, because it makes synergy completely unusable and it exists since two years now?! How about a quick and dirty workin around using a timer which releases at least ctrl, alt, win super key when they are stuck for about 5-10 seconds? I am not familiar with the code yet, anyway if there is anything I can volunteer, please let me know.

Joerg

I'm going to have another crack at this in 1.4, otherwise it'll be another year or two before it's fixed.

Task Bug

System

3

Normal High

? 1.4.5

Nick Bolton wrote:

I'm going to have another crack at this in 1.4,
otherwise it'll be another year or two before it's fixed.

I'll donate 100 EUR if this gets fixed.

I'm so tired of sticky keys, happens to me at least 30-40 times a day and got even worse in recent releases.

PS: Sorry for the chatter.

i was fighting with on OS X vs Linux. dropping back to using SynergyKM which has synergyc and synergys 1.3.1 made things work. i was not able to get any of the newer versions to get past this problem.

With Mac OS 10.7 Lion running synergys 1.4.4 with Gentoo linux clients running 1.4.4, my modifier keys will not seed at all. Instead the result is the control key on linux is sticky/stuck.

I tried playing around with the server config but nothing change the result. Happens to by about 90%% of the time.

Mac OS 10.7 Lion running synergys 1.4.4 with Gentoo linux clients running 1.4.4, my modifier keys will not send at all. Instead, when I use any modifier key, the control key on linux is sticky/stuck.

I tried playing around with the server config but nothing change the result. Happens to me about 90%% of the time.

Sorry for the double post.

Having a similar issue as Koodough Katsu. Running latest beta (1.4.4). Mac (Lion 10.7.2) as server, Ubuntu 11.10 as client.

If I press shift, control, alt, or command on my Mac while mouse is on Ubuntu side, the menubar at the top shows up as if I'm holding down the Alt key. The only way it goes away is if I move my mouse back to the Mac side. Makes it pretty much unusable. I haven't tried any other OS combinations.

I switched back to synergy 1.3.1 to resolve this show stopping issue. My configuration is Mac OS 10.7.2 and a Gnome Gentoo Linux operating system (kernel 2.6.39)

This is my configuration file. Seems to work with Synergy 1.4.4, and works with Synergy 1.3.1. On Synergy 1.3.1, mouse with disconnect for 5 seconds (~hourly rate) and any copied text, no matter the size, is slow to transfer to another computer, ranging from a couple of seconds to about a minute. This is my solution for now.

Config File, if that matters..

section: screens

    # three hosts named:  left, iMac, and right

    leftleft:

    left:

        alt = ctrl

        ctrl = alt

    iMac:

    right:

        alt = ctrl

        ctrl = alt

end  


section: links

    # iMac center

    iMac:

        left(20,80) = leftleft(20,80)

        left(20,80) = left(20,80)

        right(20,80) = right(20,80)

    left:

        left(20,80) = leftleft(20,80)

        right(20,80) = iMac(20,80)

    right:

        left(20,80) = iMac(20,80)

end  

Following Koodough Katsu's advice I tried Synergy 1.3.1 on my Mac and everything is working now. Didn't even restart latest version on my Ubuntu box.

This issue seems to be fixed for me, too. I had different keyboard layouts on the server and client. Now with identical layouts the sticky keys didn't occur for a while now...

1.4.5 1.4.6

1.4.6

Confirmed Katsu's workaround to be working on the following configuration:
Server "theMac": Mac OS X Lion 10.7.2 running version 1.3.1
Client "theLinux": Ubuntu Linux 11.10 32-bit, running version 1.3.4

Worked with this config file to fix key mappings in Linux client's PC keyboard:

section: screens

        theMac:

                super = alt

                alt = super

        theLinux:

end  


section: links

        theMac:

                right = theLinux

        theLinux:

                left  = theMac

end

I have exactly the same problem with 2 Windows 7 Ultimate 64bit PCs running Synergy 1.4.4. i.e. the Alt key gets stuck if you are still holding it down when the mouse moves from one PC to the other.

It happens a few times a day, and hitting the Alt key again solves it, so it's not the end of the world. But, it is very frustrating.

I assume from the fact that this bug is 3+ years old that it's not trivial to fix.

@Nick Bolton, I see that you deleted a Target Version. Would you mind giving an update on where this bug is at.

Having also this issue:

Synergy 1.4.5
Ubuntu Natty 11.04 both on client and server
server: 1 monitor (laptop)
client: 2 monitors (desktop pc)

sometimes Ctrl key gets stuck, restarting server is the only cure

this happens reproducibly if I keep Ctrl pressed while moving the mouse from client to server
but also other things may cause this (e.g. usage of Thunderbird 3.1.5 ??)

If anybody from the developers tells me how to debug this issue,
I am happy to do so being a developer too.

I am having the same problem with a 10.7.2 Mac to a 10.11 machine. I am using synergy 1.4.5 on both machines.

From the debug logs it looks like the fault would be on the client side

this is the DEBUG1 output from another key press, it gets both up and down signals.

recv enter, 1919,876 23 0000

entering screen

ignoring X error: 8

recv mouse down id=1

recv mouse up id=1

recv key down id=0x00000061, mask=0x0000, button=0x0001

mapKey 0061 (97) with mask 0000, start state: 0000

find best:  0000 0000

best key index 0 of 1 (exact)

found key in group 2

state: 0000,0000,1001

flip: 0000 (0000 vs 0000 in 1001 - 0000)

desired state: 0000 0000,0000,1001

flip: 0000 (0000 vs 0000 in effe - 6020)

mapped to 026, new state 0000

keystrokes:

  026 (00000000) down

recv key up id=0x00000000, mask=0x0000, button=0x0001

keystrokes:

  026 (00000000) up

recv leave

leaving screen

but when pressing any of the modifier keys, I get only this:

recv enter, 1919,729 29 0000

entering screen

ignoring X error: 8

recv mouse down id=1

recv mouse up id=1

recv key down id=0x0000efe9, mask=0x0004, button=0x003b

key down translated to id=0x0000efe1, mask=0x0001

mapKey efe1 (61409) with mask 0001, start state: 0000

find best:  0000 0001

best key index 0 of 1 (exact)

found key in group 2

state: 0000,0000,0000

flip: 0000 (0000 vs 0000 in 0000 - 0000)

desired state: 0001 0000,0000,0000

flip: 0000 (0000 vs 0001 in fffe - 6020)

mapped to 032, new state 0001

keystrokes:

  032 (00000000) down

When I leave the ubuntu I get the following

leaving screen

keystrokes:

  032 (00000000) up

and so the key is released. (This seems to be a client thing as the server DEBUG1 does not say anything about sending a keyup).

The servers DEBUG1 output for when pressing and holding the shift keys for a few seconds the shift key is:

event: Key event kind: 12, keycode=56

mask: 20102

new mask: 0x0004

onKeyDown id=61417 mask=0x0004 button=0x003b

send key down to "mediaserver" id=61417, mask=0x0004, button=0x003b

checking clipboard

flags: 0

checking clipboard

flags: 0

checking clipboard

flags: 0

event: Key event kind: 12, keycode=56

mask: 0100

Which seems to indicate that it does not send a onKeyUp when the shift key is released. If we press a regular button we get the following on the server:

event: Key event kind: 10, keycode=0

new mask: 0x0000

onKeyDown id=97 mask=0x0000 button=0x0001

send key down to "mediaserver" id=97, mask=0x0000, button=0x0001

event: Key event kind: 11, keycode=0

new mask: 0x0000

onKeyUp id=0 mask=0x0000 button=0x0001

send key up to "mediaserver" id=0, mask=0x0000, button=0x0001

I too have been plagued with this problem. Although not constant, it happens enough that it had me looking for a replacement product. If there is any workaround available, I would love to know about them.

Right now I have synergys on Win7 and a synergyc on RHEL 6.2. I have tried various versions icncluding 1.3.8 and 1.4.5 on the client and the server and the problem is always there.

Thanks.

High Urgent

1.4.8

Urgent High

Looks like the modifier masks being used in COSXKeyState::mapModifiersFromOSX are wrong. cmdKey is 0x100 which is always on in the mask, therefore every modifier is registering as cmd, and it's getting stuck 'down'.

By experimentation I have found the following masks work for me

if ((mask & 0x20000) != 0) {  
    outMask |= KeyModifierShift;  
}  
if ((mask & 0x40000) != 0) {  
    outMask |= KeyModifierControl;  
}  
if ((mask & 0x100000) != 0) {  
    outMask |= KeyModifierAlt;  
}  
if ((mask & 0x80000) != 0) {  
    outMask |= KeyModifierSuper;  
}  

I have caps lock remapped locally and don't have a numlock key so I can't tell you the other two values, but perhaps the values above will give a clue as to which masks should be used.

When I used the code above, everything was working except that option mapped to the windows key wasn't working correctly as a modifier key - it was as if the client didn't register the windows keydown until a second key was pressed and then the second keypress acted like a single down-up of the windows key (e.g. windows-R popped up the XP start menu instead of opening the Run dialog). Strangely when I configure as alt=super/super=alt both keys seem to work correctly.

Apologies for the partial information - unfortunately I don't have time to delve deeper, but if I can run any other tests/diagnostics for you locally let me know and I'll do my best.

Server OS X Lion 10.7.3/Synergy 1.4.7, Client Windows XP SP3/Synergy 1.4.7

PS here are the actual mask values being reported on the various modifier keys

left shift: 20102
right shift: 20104
control: 40101
left option: 80120
left command: 100108
right command: 100110
fn: 800100

I don't have a value for right option either, but looking at pattern that I'd be surprised if it wasn't 80140

1.4.8 1.4.9

Win7 64 on both machines.

Had no issues for the first month.

Then ctrl started getting stuck maybe 20-40 times in an 8hr day.
Fixed for a week or so by changing hot keys to alt-shift+f11/f12.

Then, starting yesterday, shift stated sticking every 3-10 seconds. I was not even switching between PCs! I could not type a sentence without pressing shift a few times to unstick it. I assumed my keyboard was dying, cleaning didn't help ofc. I found a very nice keyboard to replace this g110 - [[http://www.newegg.com/Product/Product.aspx?Item=N82E16823816002]] But I connected the other PCs keyboard here, and the problem persisted. So much for my splurge on a new keyboard :/

I had done some things with AHK two days ago - but after reboot, the new AHK was no longer loaded but the problem persisted. (I still have my trusty insert-date AHK running, but that has been there since day 1 with Synergy)

I've searched for a way to send a key without using ctrl shift alt... For example, I could program my keyboard to send mouse-4 and mouse-5 but these seem to be bugged on the Logitech gaming software, and Synergy does not let me program the middle button so probably wont take button 4-5 anyway.

I'd love to see a Synergy command line to switch PCs. That way I could use the G keys to send that command. Like when I press the G1 key (Logitech G11 special key) it would run:

Synergy /goto PC1

I bet this would also help other users in other ways.

Also, if the problem persisted, it would not be a Synergy issue.

I've had good luck with this change:

diff -rub synergy-1.4.6-Source/src/lib/synergy/CKeyState.cpp synergy-1.4.6-Source.mod//src/lib/synergy/CKeyState.cpp

--- synergy-1.4.6-Source/src/lib/synergy/CKeyState.cpp  2011-06-18 18:39:56.000000000 -0500

+++ synergy-1.4.6-Source.mod//src/lib/synergy/CKeyState.cpp     2012-03-13 09:18:30.000000000 -0500

@ -664,20 +664,25 @

        m_serverKeys[serverID] = 0;  


    // check if this is a modifier  


-       for (ModifierToKeys::iterator i = mactiveModifiers.begin();

-                                                               i != mactiveModifiers.end(); ++i) {

+

+       ModifierToKeys::iterator i = mactiveModifiers.begin();

+       while (i != mactiveModifiers.end()) {

                if (i->second.mbutton == localID && !i->second.mlock) {

                        // modifier is no longer down

                        KeyModifierMask mask = i->first;

-                       mactiveModifiers.erase(i);

+

+                       ModifierToKeys::iterator tmp = i;

+                       ++i;

+                       mactiveModifiers.erase(tmp);  

                    if (m_activeModifiers.count(mask) == 0) {  
                            // no key for modifier is down so deactivate modifier  
                            m_mask &= ~mask;  
                            LOG((CLOG_DEBUG1 "new state %%04x", m_mask));  


                        }


break;  
}  
else {  
++i;

            }

    }

Accepted GotPatch

1.4.9 1.4.8

Thanks for the patch, I'll apply that now so people can test it in the nightly build.

r1335 contains this patch, available from the nightlies: http://synergy-foss.org/nightly/

Only the Windows build is working right now, I'm going to spend tomorrow getting the other builds back online.

After running for over a week with this patch (and thinking that it worked), today I encountered the sticky modifier issue again.

george pee wrote:

After running for over a week with this patch (and thinking that it worked), today I encountered the sticky modifier issue again.

I'll test this as well when Linux binaries are available but I can confirm that I've been fooled myself into thinking that everything was better for over a week as documented further up this ever expanding thread of comments. The only solution that has ever worked for me over time (and what I'm still doing now) is going back to 1.2.6 which uses protocol version 1.2; there are some other annoyances but no stuck keys for me when used between a Linux host, one Linux guest, and one Windows guest (either XP or Windows 7 64-bit).

Please post again if you want additional testing with your patch and best of luck!

A.C.
******

1.4.8 1.4.9

GotPatch Accepted

1.4.9 1.4.10

1.4.10 1.4.11

This problem seems to be far worse when combined with the use of remote desktop on the Server. I've spent 30 minutes looking for a fix for Hyper-V which is not responding to my ctrl-alt-end (delete) because of sticky Metas.

I think it is noteworthy that this does trigger problems within the X server itself. Even after killing syngery(c/s) the sticky keys remain. Restarting my window manager (gnome-shell) does not help either. I have to restart X to get rid of the issue.

System: Fedora, 64 bit, tried different synergy versions, 1.3.4 and newest nightly: 1.4.11-r1659. Server and client both running linux.

I havent read all of posts, but I have a 100%% repro on my set up.

1) With server machine in focus, hold down shift. 2) With shift held move to client machine 3) Release shift while on client machine. 4) Move back to server

As the shift hold was sent on the server, but the release was sent to the client the server machine still thinks the modifer is held.

I have this issue as well.

Synergy 1.4.10 Server: Windows 7 sp1 Client: OS X 10.8.1

I use shift+alt+j to switch left and shift+alt+k to switch right. Using the onscreen keyboard in windows I can see that if I use the hotkeys to switch and then use the mouse to come back to the server the shift and alt keys remain pressed.

I'm not able to recreate the behavior on OS X. The on screen keyboard shows the keys pressed and released properly.

I've tried the hotkeys set for 'on press' and 'on release', with no discernible difference. I can recreate it 100%% by doing log keypresses on shift+alt. If I more 'chord' and quickly release shift+alt it happens less frequently.

As an aside the software MouseShare has EXACTLY the same behavior.....

I encountered a strange and frustrating variation of this bug today. My synergy server (OS X) started having some issue where it was mixing up keyboard input on some keys. I am unsure if this is related to synergy or not, but 'space' would change focus away from the active window making any typing near impossible. Other keypresses would open up random apps and the behavior became unpredictable and unusable, so I rebooted the Mac.

After restart, I started synergy again and it would work fine, but after entering and leaving the client (Linux), and entering the client again, any keyboard input would behave as though CTRL was being held down on the client side. I tried typical remedies of hitting all of the meta keys to 'reset' them, and restarting the server and stopping and starting the client (but not terminating synergyc), but the behavior persisted. After looking at the interactive keyboard mapping and experimenting with key presses, I noticed that the synergy server seems to only send LEFT meta key codes, regardless of which physical right or left key was hit. I connected my keyboard directly to the client and hit RIGHT CTRL and immediately the stuck key behavior ceased, and everything worked properly again.

My theory is that whatever random key codes my server was sending when its keyboard input was malfunctioning, it must have sent a RIGHT CTRL to the client that got stuck. It was then impossible to 'unstick' the client host via synergy, because the server will never send the RIGHT CTRL code, only LEFT CTRL

server: Synergy 1.4.10 on OS X 10.7.4

client: QuickSynergy 0.9.0 on Ubuntu 11.10

I'm seeing the same issue as Christopher Hunter and its driving me crazy! Once the ctrl key locks in Ubuntu I have to pull the plug on the machine as I can't type in a terminal or click a button.

I'm not 100%% sure what triggers it, its not as simple as crossing screens with CTRL key pressed or pressing on one and releasing on another. It happens several times a day.

Server: synergy 1.4.10 on windows 7 Client: synergyc 1.3.8 on Ubuntu 12.10 (the one that comes in with apt-get: is this a very old version?

update on the above- can't reproduce what causes the problem but pressing the RIGHT ctrl key on the client releases it when it becomes stuck (on the ubuntu client)

Similar problem as above, not that the above problems are all the same.

I would get the "control-key" stuck when I entered the X-window client. Restarting either the synergyc or the synergy server would clear the problem, but the problem would return after a small number of entries and exits.

Setting the keyboard layout to "U.S. English" instead of default solved my issue.

An easily reproducible variation on this bug:

Server: Windows 7 x64 / synergy 1.4.10 Client: FreeBSD 9.0-RELEASE-p3 amd64 / synergy-devel-1.4.10

1. With the mouse on the server, press and hold down the shift key.
2. Continuing to hold the shift key, move the mouse to the client.
3. Release the shift key.
4. Move the mouse back to the server.

Your Windows meta key no longer works on the server. Tap shift to get it back.

I've recently been looking at this behaviour with the "xkbwatch" utility. This hopelessly underdocumented utility shows the on/off state of the modifier keys as a set of "lights" on a display. The modifier is an 8-bit mask and is displayed by xkbwatch with the most significant bit on the left and least significant bit on the right. xkbwatch also shows a set of rows that correspond to "base, latched, locked, effective, compat" but we can (I think) ignore these states for now.

The command "xmodmap -pm" lists the keys that make up the bitmask from LSB to MSB, but a small amount of experimentation is enough to observe what the flashy lights are doing in any case.

The interesting finding I had using this tool is that the keys are not getting "stuck down" in so far as X is concerned -- xkbwatch clearly shows the keydown then keyup events being relayed to the client system. When I end up in a "sticky modifier keys" situation, the modifier key is off until I press any key on the keyboard. Then the modifier comes back on automatically. Pressing the modifier key that is reported by xkbwatch twice then causes it to be released and any keystroke or mouse movement can be performed without the action of that modifier. After the next keystroke, however, the modifier will go back on again.

To give a concrete example that might be easier to follow, xkbwatch might show me that "shift" has stayed down for some reason (to do with any or all of the reasons speculated about in this bug report). If I were to press "a" I'd now get "A". If I hit then the shift key is no longer shown as down and pressing "a" gives "a" but then the shift key is shown to be pressed immediately again. I've also seen this behaviour for other modifiers; I'm just illustrating it with "shift" here because when it's "shift" you just get some uppercase letters or selecting text with the mouse; when it's ctrl, alt, super etc then you are running keyboard shortcuts and all manner of amusement can ensue.

So this isn't so much a case of the modifier being "sticky" as it wanting to turn on again all by itself. As others have reported, repeatedly hitting that key can be enough to convince it to stop turning on like this. It seems to happen most when touching keys that synergy for some reason thinks also involve ISOLevel3Shift (that's commonly < > @) I can't, however, point you to the bug that discussed that in detail as the old sf.net bug tracker seems to have been removed but it's probably been reported again as http://synergy-foss.org/spit/issues/details/71/.

I hope this is a useful piece of information to add to the debugging effort (and perhaps a useful tool to help with the debugging).

I am also experiencing this issue. While it has happened periodically in the past, today it seems to happen every time I turn around.

I also am having no luck figuring out which meta key is stuck, which results in me having to SSH into the machine and killall synergyc. Unfortunately, even that is not possible sometimes since my Windows machine's keyboard will have the same issue, preventing me from even entering a password or login.

I have noticed this behavior on both the client and server. My server is a Windows 7 x64 machine, and the client is a BackTrack 5r3 machine. I can replicate the issue by holding down the key, though today I have not been able to make it replicate reliably. But if I give it 15-20 minutes, it invariably occurs and causes all kinds of problems.

Not sure if it's Synergy causing this, but my keyboard periodically resets. I see the three status lights for the "lock" keys flash. It seems like this event is linked to having sticky keys on my machine, although it may be a completely separate issue. I have the meta key problems most often. I use the Win+L shortcut to lock the desktop. I also use Remote Desktop frequently. I have had non-meta keys stick, but it's usually obvious when that happens: I start seeing a string of characters going across the screen. I have had the backspace/delete characters stick too, which can be particularly disastrous as others have pointed out.

Just Several Observations, No technical Data maybe something useful can be extracted from this.

I've noticed I dont even have to hit the modifier keys while running synergy for one of them to simulate getting stuck(this behavior dont happen when synergy isnt running so it likely isnt a device fault), this most commonly happens with alt, this also happens with the arrow keys on the keyboard a lot for me, another odd observation is I've noticed the stuck keys can sometimes be a specific alt Key on a specific Input device(IE Multiple keyboard like Input devices), I used to use a Belkin Nostromo N52 in addition to the standard keyboard which could send its own modifier key strokes and sometimes I could tap alt keys on the standard keyboard and not cause a key release for alt until I tapped it on the Nostromo N52, (the Belkin version of the device had its own onboard memory and thus then sends raw input, rather than relying on a background application to translate keystrokes to other keystrokes like the razer version of the device), unfortunately my roommate broke it and replaced it with the Razer Version of the same device so I can't be asked to yield test data for this behavior.

Some Additional Observations I've had though is that Maybe the problem Lies in Synergy's communication protocol what I've observed suggests the protocol could be more robust and may need to be re-implemented in a more fault tolerant manner, I'm Into PC gaming and Secondlife I've noticed some various behavior aggravates the issue, within Secondlife I've noticed in my router Logs occasionally I have problems with my connection getting flooded by Linden Labs servers regardless of network settings in it's client, while possibly unrelated, I've noticed on a few occasions during this flooding Modifier keys sent by synergy would become sticky, I'm not exactly using the most robust router and external network traffic can cause a little internal packet loss. Also some packetloss occurs when the client or server may receive low frame rate during gameplay, some of the more intensive or poorly designed games that I play will occasionally have framerate issues that briefly(several seconds) drop their frame rate below 15 FPS, I've noticed during these intensive moments is the most common times when the stuck modifier keys begin to occur, however on the other hand it is also not unseen that these issues can occur when the system is under a light workload... it just happens a whole lot less often.

I've also Observed this issue is sometimes briefly fixed by disconnecting and reconnecting the device if your using USB input, but will oftentimes re-occur shortly later, I've also had problem Free runs where synergy would not cause an issue, however generally if sticky modifier keys occur, they are likely to persist, and also as with such I've noticed both client and server seem to harbor the problem, if I restart either system client or server and start synergy again after reboot the problem oftentimes recurs, however if I am to completely restart both machines the problem will no longer persist, I've also noticed that just simply killing the client and server on both machines and starting them back up again doesnt always fix the problem, a Full restart of the PC regardless of OS is oftentimes needed.

I apologize for the long set of observations, I really would like to see these problems fixed as Im a fanatic about accurate control and Primarily a linux user which limits my alternatives, I felt they were worth mention as I actually Had to recomend to someone the other day that they don't use synergy because they were talking about using it in a setting where it is likely to be highly disruptive to their profession with the presence of this ongoing bug and them being a windows user have alternatives available, however I would like to be able to recomend synergy in the future as it is the Only Open Source Software KVM I know of, I just cant recomend it in this state.

Yup, very frequent here too.

Setup: 2x Windows 7 Ultimate x64 1x Windows 8 Professional x64

I am seeing it a lot, some almost at random, but one that is nearly a guarantee is (with no hotkeys configured) when working in Visual Studio 2010/2012 Ctrl+Shift+[Right|Left], to try to begin making a selection one word at a time.

After upgrading to Synergy 1.4.11 (Windows 7 PC) I noticed that I could no longer click and drag to highlight text in the Chrome browser address bar.

I did lots of Google searching and found mention of it being a bug in Synergy.

I also found that if I pressed the Alt key, followed by the Windows Key, followed by the Ctrl key then I could left click and drag to highlight text in the Chrome address bar, but as soon as I hit any other key the bug would re-enable.

The inability to select appeared to be only in the Browser Address bar, so although annoying not so bad.

I however have just discovered it also stops selection tools in Photoshop which is a major issue.

I just un-installed Synergy from my PC and as soon as I did the bug completely disappeared. It is without a doubt being caused by Synergy.

Of special note is that whilst I normally use Synergy to control my Win 7 PC and Linux Mint box, I have not had the mint box turned on all week and Synergy has not been running on my PC yet the bug was causing problems.... There was a Synergy process (syngergyd.exe ?? sorry forgot to write it down before uninstalling) which I was unable to terminate.

Also found this online which seems to be related. http://superuser.com/prevents-click-and-drag-actions-in-some-windows-applications

Hope this helps!

Can confirm this is a problem on a Windows 7 x64 serve with a Mac Mini OS X 10.8 client. Generally the issue happens with the client (CTRL is stuck) and it ALWAYS Happens when I have NOT pressed ctrl. So I can confirm what is happening on the first part of Mina Hew's comment. This and the OS X sleep/wake bugs are quite frustrating as they are impacting the total day-to-day usability of Synergy. That said, it is still an amazing product and I have found pressing the ctrl key a few times on the client that is stuck will unstick it.

Can confirm this is a problem on a Windows 7 x64 serve with a Mac Mini OS X 10.8 client. Generally the issue happens with the client (CTRL is stuck) and it ALWAYS Happens when I have NOT pressed ctrl. So I can confirm what is happening on the first part of Mina Hew's comment. This and the OS X sleep/wake bugs are quite frustrating as they are impacting the total day-to-day usability of Synergy. That said, it is still an amazing product and I have found pressing the ctrl key a few times on the client that is stuck will unstick it.

This is exactly whats happening for me on all modifier keys. Win7x64 server and OSX 10.8.4 client. Really annoying when I'm trying to get to grips with OSX keyboard shortcuts! Please fix!