search

symless / synergy-core

Open source core of Synergy, the cross-platform keyboard and mouse sharing tool (Windows, macOS, Linux)
https://symless.com/synergy
Other
10.13k stars 3.6k forks source link

Modifier/meta keys get stuck down #9

Closed nbolton closed 9 years ago

nbolton commented 9 years ago

Imported issue:

What steps will reproduce the problem?

  1. Problem occurs immediately after moving from one desktop to another
  2. Can occur when moving from server to client or from client to server
  3. Problem is sporadic - happens some of the time when
    moving from one desktop to the other
  4. I am not aware of a particular sequence of steps that are guaranteed to
    reproduce the problem

What is the expected output? What do you see instead?
I expect that typing or clicking the mouse will have the normal effect.
When the problem occurs, the computer acts as if a meta key such as ctrl or
alt is being held down.
To resolve the problem, I have to press each meta-key on the keyboard until
I determine which one the computer believes is being pressed.

What version of the product are you using? On what operating system?
Synergy 1.3.1 on XP SP2

Please provide any additional information below.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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)?

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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...

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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?

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

-Missing comment-

nbolton commented 9 years ago

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

nbolton commented 9 years ago

-Missing comment-

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

Interesting.

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

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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?)?

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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!

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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?

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

-Missing comment-

nbolton commented 9 years ago

Issue #google:6 may help as a work around.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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+.

nbolton commented 9 years ago

-Missing comment-

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

@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. :-(