search

deskflow / deskflow

Deskflow lets you share one mouse and keyboard between multiple computers on Windows, macOS and Linux. It's like a software KVM (but without video).
https://deskflow.org
GNU General Public License v2.0
13.61k stars 3.79k forks source link

Keys will randomly be repeated at length on client #375

Closed nbolton closed 2 months ago

nbolton commented 10 years ago

Imported issue:

IMPORTANT: Please research your problem thoroughly before opening
a new ticket. The following tips are provided to help you.

What list of steps will reproduce the problem?

Doesn't happen predictably, don't know how to reproduce.

What version of operating system, and Synergy+ are you using?

Server is running XP Home Edition, client is running Ubuntu 9.04. Synergy+
is 1.3.4.

What is the expected behaviour, and what happens instead?

Occasionally a key that I've only struck once is repeated many times -
anything from five to thirty.

Is there a way of temporarily working around your problem?

Well, I can delete the extra characters entered.

Would you like to solve the problem yourself and submit a patch?

I can't code, so.

nbolton commented 10 years ago

Seeing the same problem.

Synergy+ version 1.3.4 on all systems
Server is on Ubuntu 9.10, as is the client.
The same problem was observed with Ubuntu 9.04 on the client system.

The bug seems to arise in conjunction with temporary network glitches (both systems
are on a not-very reliable wireless connection). Other applications time out/hang
momentarily and synergy produces a long repeated sequence of the last key pressed.

nbolton commented 10 years ago

I get this issue when the battery on my keyboard is running low... Are you guys using
wireless keyboards at all?

nbolton commented 10 years ago

I'm just using my built-in laptop keyboard. It does it when something takes up too
much CPU on the server for a bit, but also randomly at other times.

nbolton commented 10 years ago

Thanks. Could you attach some debug logs?

nbolton commented 10 years ago

Happens to me too on radom but frequently.

Server: Win XP
Client: openSUSE 11.1
Synergy+: 1.3.5 RC

nbolton commented 10 years ago

Also affects Mac 10.6 server and CentOS client. A keypress will either not register or will repeat until another key is pressed. Both machines use wired connections, no wireless or other networking issues to speak of. Both using same version (1.3.4). Due to bug 349, I don't know if it affects CentOS server and Mac client.

nbolton commented 10 years ago

I wrote:

Also affects Mac 10.6 server and CentOS client. A keypress will either not register or will repeat until another key is pressed. Both machines use wired connections, no wireless or other networking issues to speak of. Both using same version (1.3.4). Due to bug 349, I don't know if it affects CentOS server and Mac client.

I've upgraded both machines to 1.3.6, and this problem seems to have been fixed. In addition, using --no-xinitthreads allows me to run with CentOS as server (bug 349). I have been running with CentOS server/Mac client for a couple of days now, and have not seen this problem occur. It used to happen very regularly. I have not spent much time with Mac server/CentOS client configuration.

nbolton commented 10 years ago

Jascha, thanks for updating the issue. I'll mark it fixed based on your feedback.

If this issue should be reopened, please ask on the mailing list.

nbolton commented 10 years ago

Any chance this fix regressed in 1.4.2?

I suddenly started seeing the described behavior for the first time this morning, after my client system (linux: Gentoo ~x86_64 on a Thinkpad t61p) picked up 1.4.2 out of portage during a system update. (I'd been running 1.3.6 previously.) Server system is Fedora 12 -- was running 1.3.1, but updating to 1.4.2 from the RPMs hosted on this website failed to fix the problem so client-side code is at issue.

Reverting the client to 1.3.6 (with the server still running 1.4.2) seems to have made the problem go away, so I'll stay away from 1.4.2 on the client to solve my immediate problems but I figure you'd like to know anyway... :-)

nbolton commented 10 years ago

I'm having this problem with Synergy 1.3.7 on a couple of Fedora 15 machines.

nbolton commented 10 years ago

I tried reverting to Synergy 1.3.6 and the issue persists.

nbolton commented 10 years ago

I've experienceeeeeeed (see? now that is ironic) this issue on any 1.4.x version I've tried. It doesn't happen when using ethernet, only wireless, so I assume its has somethign to do with those packets dropping and the server reissuing them.

nbolton commented 10 years ago

I really don't think this is fixed. I get repeating keys a lot recently. Version 1.4.12 on both ends.

nbolton commented 10 years ago

Just want to report this error as well. Repeats every couple of wooords.

Serverrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

> uname -a:  
Linux asus-1000HE 3.5.0-42-generic #65~precise111-Ubuntu SMP Wed Oct 2 20:57:24 UTC 2013 i686 i686 i386  GNU/Liiiiinux

> synergys  --version
synergys 1.4.12, protocol version 1.4
Copyright (C) 2012 Bolton Software Ltd.
Copyright (C) 2008-2012 Nick Bolton
Copyright (C) 2002-2012 Chris Schoeneman

Client

> uname -a
Linux hp-dm1-4050us 3.2.0-56-generic #86-Ubuntu SMP Wed Oct 23 09:20:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

> synergyc --version
synergyc 1.4.12, protocol version 1.4
Copyright (C) 2012 Bolton Software Ltd.
Copyright (C) 2008-2012 Nick Bolton
Copyright (C) 2002-2012 Chris Schoeneman

The mouse also skips around a lot, very discontinuous, expect they're related. Feels more like a network problem. Could the problem be with the router rather than the computers? I'm using a Linksys WRT54GL running the Tomato firmware. Rebooting the router doesn't seem to make much difference though. Any other troubleshooting ideas?

nbolton commented 10 years ago

Also tried changing to a wireless channel with no other signals on it, but still same performance. Tried both channel 7 (2.442GHz) and 10 (2.457GHz), but same on both. Computers are about 15ft away from the router, fwiw.

nbolton commented 10 years ago

Also this issue and a workaround for OS X: http://synergy-foss.org/spit/issues/details/3111/

nbolton commented 10 years ago

I experience the same issue on a Microsoft Surface Pro 2 running ArchLinux (synergy 1.4.15) with gentoo box as server (also synergy 1.4.15).

The surface pro 2 hase a very problematic wifi chip/driver (marvell) and wifi is erratic (sometimes experiencing extreme lag and ping-time in the seconds).

However this should not really lead to dupllllllllllicated characters.

What can I do to help?

nbolton commented 10 years ago

Also experiencing this problem, Win7 server, Ubuntu client. Wired connections on both machines, USB keyboard + mouse. Synergy 1.4.15. Willing to help.

nbolton commented 10 years ago

I reopened the bug since several people have commented that it's still happening.

nbolton commented 10 years ago

This is happening quite often for me, as well.

Server: Mac OS X 10.8.5, Synergy 1.4.15 Client: Slackware 14.1, Synergy 1.4.15

It seems to be much more easily reproducible when typing very quickly and when using more than one key at once. (I'm a heavy emacs user, and key combos lead to repeat characters very easily.)

Here's a snippet from the log in the server window (running on Mac OS X):

INFO: entering screen
WARNING: cursor may not be visible
NOTE: unknown quartz event type: 0x1e
NOTE: unknown quartz event type: 0x1e
.... (The line above repeats many times.)
nbolton commented 10 years ago

Same issue but quite often randomly repeated characters same repeating entry in synergy server log unknown quartz event type: 0x1c. OSX Synergy server RHAT 6.0 synergy client Windows 8 synergy Client, regardless of wired or wireless connectivity.

nbolton commented 10 years ago

Yeah i have just started getting this too. It is total balls.

Do the synergy developers not realise that bugs like this mean the software is pretty much unusable?

nbolton commented 10 years ago

Same issue here, but random-ish. Server 1.4.15 on Windows 8.1, Gig-E Wired connection, Client 1.4.17 on Manjaro-Netrunner.

nbolton commented 10 years ago

Same problem here. Ubuntu 12.04 and Synergy 1.5.1 on client and servers. Repeated keystrokes happen at random and quite frequently, so that using synergy becomes a nightmare. I love this piece of software and would like to be this issue fixed or a workaround available.

Thank you very much!!

nbolton commented 10 years ago

Problem update: I just traced the problem back to a network reliability problem (as was already suggested above by a couple of the issue reporters), in this case due to a faulty network switch. I didn't evaluate how severe was the network problem (as the connection speed seemed to be ok in standard use with web browsers and terminal sessions), but when I changed the switch, the problem stopped. I wonder if the bug still happens with reliable network connections, but I suggest to first check how good is you link. Thanks.

nbolton commented 10 years ago

I don't believe my issue is network related. I upgraded the firmwares on my GS716T switch and rebooted client, server and switch with no change in key repeating. However I did find a workaround of sorts. In your keyboard settings of the client that is key repeating, simply disable the key repeat option. This will make Synergy somewhat usable.

mrdomino commented 10 years ago

I'm experiencing this with synergy(s) 1.6.2 on OS X and synergy(c) 1.6.1-1 on Arch Linux. It appears likely to be related to network latency.

BrianHoldsworth commented 9 years ago

summary - this comment is all lower-case because i reverted to synergyc 1.3.1 to fix the repeating keys problems, and now the shift-key modifier is ignored.

longer version - i am running latest synergys on morphos as my server, and client is current ubuntu 15.10. i experienced the repeating keys issue with the standard ubuntu synergyc version 1.6.2. i then built binaries and found the problem was still present in latest code from github, and old version 1.4.1, and old version 1.3.6. i then went all the way back to 1.3.1 because i have that version running on a mac client and there is not repeating keys problem. with some serious consternation, i was able to build 1.3.1 on ubuntu 15.10 and see now that it also does not suffer from the repeating keys. however, the shift key is not recognized.

throughout my testing, the easiest way to recreate the repeating keys issue was to simply open an xterm on the client and type a command, followed by return. after a short pause, i would always get a long repeating stream of returns in the xterm console. it stops as soon as you press some other key.

i would say this bug was introduced in between 1.3.1 and 1.3.6 and is still present in the latest source code from github.

mxyzplx commented 7 years ago

Is this still an issue that's being considered? I've been experiencing it... seems like forever now. Have an Ubuntu 16.10 server, wired, and an Ubuntu 16.10 client, wireless (although it makes no difference if it's wireless or wired). This has been an issue with the stock version of synergy available in the Ubuntu repositories (1.6.2), and the latest available version (1.8.7), and seems to have been an issue for as long as I can remember.

I've tried lowering the MTU on both machines; creating a QoS rule in the router for the application; forwarding the port on the router and in the firewalls; and I ticked "Check clients every 5000 ms" simply because I didn't see what that does in the wiki, and wanted to see if it would make a difference.

So far nothing seems to make a difference, and iiiits gettttttttttttting very irrrrrrrrrrrrrritating havvvvvvvvvvving to delllllllllllete soooooooooo many lettttttttttters alllllllll the timmmmmmmmme.

xhou-wavefin commented 7 years ago

Close as an obsolete issue

hmcclungiii commented 7 years ago

How is this issue closed? Server: Windows 10 Client: Ubuntu 16.04

5AMsan commented 7 years ago

Same issue. Server: Windows 10 Client: Ubuntu 16.04

wbarksdale commented 4 years ago

Same issue Mac OSX 10.15.6 and Ubuntu 16.04 LTS. Mac OS is the host.

hcaiano commented 4 years ago

Same issue on Windows 10 on both client and host.

AJChapman commented 4 years ago

Same issue, on a home wifi network, client and server both running NixOS (Linux), Synergy version 1.11.1. It's a very frustrating experience, as you can still get things done, but you're continuously undoing the mistakes the keyboard forces you to make.

Note that on both server and client I have a high key repeat rate set, using xset r rate 200 100. Could this be contributing to how often I see the issue? If so then it could help for reproducing the bug.

andreacndn commented 4 years ago

@AJChapman could you please confirm if you experience the same error on 1.12.0?

Thanks, Andrea VP of Technology @ Symless

justinaquino commented 4 years ago

experiencing the same. ubuntu 20.04.1 only on Client System. Google Wifi Synergy 1.12.2 Build date Nov 12 2020. I end up only writing at length in the Server Computer (opening the Gdoc in this computer).

klieret commented 3 years ago

I also see this issue with 1.14.0-stable-67d824b8 built June 8 2021 on ubuntu 19.10 and ubuntu 18.04

This isn't only frustrating but downright dangerous, especially when writing in the command line.

klieret commented 3 years ago

It's probably best to disable key repeat (i.e. that a key is repeated after a key is pressed for x ms) while this is an issue. An easy way to do so on Ubuntu with gnome is Settings > Universal Access > disable Repeat Keys

allanwmacdonald commented 3 years ago

I just had this happen with Win10 server and Ubuntu 20.04 LTS Client: When I hit the screen lock key sequence on the client, (winkey-L), both the client and server lock at the same time because the windows server picks up the key sequence regardless of mouse focus. The result: a bunch of *** appear in the password entry field in the locked screen on the ubuntu client. When the client was subsequently unlocked, the window that had focus was a terminal window and a bunch of line feeds caused the previous content in the terminal to be scrolled up out of view.

The workaround suggested by klieret points to the issue of how Synergy manages key repeats.

It is my understanding that, on a windows machine (server), when a key is held down, a WM_KEYDOWN event is sent, a wait of 500ms occurs and then repeated WM_KEYDOWN events are sent ("typematic" sequence). When the key is released, the WM_KEYUP event is sent to terminate the typematic sequence.

I may be guessing at this point but perhaps Synergy server has been designed to somehow manage how many keydown events to send to the client and this mechanism is being broken by some action on the server or by some interruption over the network. The client is then interpreting this error as a continued repeated key event instead of just resetting its state when the keydown events cease.

allanwmacdonald commented 3 years ago

Otherwise, I cannot think of an intended reason the client would generate repeated key events out of the blue and that would be a more dangerous situation (buffer overflow or uninitialized pointer).

nbolton commented 2 months ago

This issue has been inactive for a while so I'll close it. Please let me know if this is still an issue and I'll reopen it.

denravonska commented 2 months ago

This is still an issue. I'm on 3.0.73.7-rc2. Will try to upgrade to see if it fixes things.

nbolton commented 2 months ago

3.0.73.7-rc2

Thanks for letting me know. Reopening.

denravonska commented 2 months ago

I upgraded to 3.0.80.1-rc3 and haven't seen it since. However, I also disconnected from the company VPN at the same time. Reconnected now to see if I can trigger it again.

Edit: Yeah, I'm not seeing it at all after the update. Even with the VPN running.

nbolton commented 2 months ago

I upgraded to 3.0.80.1-rc3 and haven't seen it since. However, I also disconnected from the company VPN at the same time. Reconnected now to see if I can trigger it again.

Edit: Yeah, I'm not seeing it at all after the update. Even with the VPN running.

Ok, I'll tentatively close this as I haven't seen it recently either. Not sure what might have fixed it, but I was out of the loop for a bit with bug fixes. Let me know if you see it again in latest and I'll reopen.