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.14k stars 3.61k 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

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

Hi,

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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 .

nbolton commented 9 years ago

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

Setup #1

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

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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)

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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);  
    }  
}
nbolton commented 9 years ago

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

nbolton commented 9 years ago

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)

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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/

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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)

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

I have a new Win7 installation (as synergy server) and had different Alt-Tabbing
problem (possibly Vista/Win7 specific one). The issue #google: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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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.

nbolton commented 9 years ago

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!

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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

nbolton commented 9 years ago

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