Synergy

Google user: twentyafterfour

I can confirm this is a problem for me as well with client and server both running OS
X 10.5 so it's not just a cross-platform issue. I think it has to do with changes in
the 10.4 or 10.5 OSX SDKs

Google user: twentyafterfour

also I've noticed that the cursor keys work, just can't type anything. strange

COSXKeyState.patch - 27 Aug 2010 23:34

Google user: bernd.kilga

This fixed it for me.

It's as revert of "10.6 SDK changes" done by sorin.sbarnea on March 24th. The patch
will most likely break 10.6 compatibility.

Google user: twentyafterfour

compiling snergyc with this patch works ok but the synergys binary still won't
transmit most keystrokes

New Accepted

?

Google user: nick.bolton.uk

nobleclem, thanks for the bug report. bernd.kilga, thanks for the patch. If this has
not been applied already, I will do this my self.

keystroke.patch - 27 Aug 2010 23:34

Google user: edw...@carrel.org

Attached is a patch to my patch that makes sure the event really gets posted to the
event stream. I had neglected to do this in the prior build, and somehow never
noticed the problem.

Hope this clears up issues with this.

Google user: bernd.kilga

Your patch works great for me. Just wanted to let you know, however twentyafterfour
might still have issues with "most keystrokes" I wasn't able to reproduce.

Google user: bernd.kilga

I've used your patch the whole day and I get way more sticky keys than usually. Often
even can't get rid of the shift-key without pressing it on the client keyboard.

sticky_log_2.txt - 27 Aug 2010 23:34

Google user: edw...@carrel.org

Interesting. Any indications that the shift-key is making it to the client? Does this
happen every time you hit the shift-key while in the client? Does the same behavior
happen when the server is the active display?

Any logging you can provide might prove really useful in tracking this down.

Google user: bernd.kilga

I'll leave the log files on for today and try to get as much data as possible. (I'm
working constantly with Synergy and hope I'll find the cause)

Google user: bernd.kilga

I was able to reproduce the sticky key several times today: Unfortunately it seems to
a timing problem, I can't really describe it other than this:

My goal was to type Ffffff (Shift-Down -> f -> Shift Up -> f -> f -> f -> f -> f),
the result in the log is: FFFFFF. Pressing (down+up) shift one more time removes the
stickiness, when the stuck modifier gets carried back to the server I had to press
shift on the client keyboard to reset the status. Unfortunately I don't have a log
file of the server, the log screen clears when minimizing.. brr

I tried the above experiment multiple times and was able to reproduce it VERY OFTEN
with every multiplier (shift, ctrl, alt, windows-key) and with a lot of keys (f, k,
m, l, etc.). If you give it a spin I'm sure you'll get the same result within a short
period of time.

It seems that the exact moment when releasing the modifier key, is causing the
stickiness, for example releasing Shift and pressing f at almost the same time.

High Urgent

Keyboard does not work with Mac OS X (10.5) as client

Google user: nick.bolton.uk

-Missing comment-

-Missing comment-

Google user: nick.bolton.uk

Google user: nick.bolton.uk

server_keyboard.patch - 27 Aug 2010 23:34

Google user: edw...@carrel.org

Hi bernd,

In the process of attempting to reproduce your shift key repetitiveness problem, I
discovered a different issue entirely. When running MacOS as the server under my
initial patch, nothing as far as raw character data is concerned gets passed to the
client.

This was due to two separate oversights on my part: a NULL check that was inverted,
and a CFDataRef I wasn't breaking out before using the data therein. This and the
patches above will teach me to do more testing before sending patches out to the
general public.

As for the sticky modifier problem, I was able to send it into an odd state where it
started sending multiple ups and downs at a time when I hit the ALT key. I dug into
to try and find out what was going on, but unfortunately, killing and restarting the
server cleared the problem up without me getting any forensics first. Sad. I'll keep
into it.

Accepted Fixed

Fixed InProgress

Google user: nick.bolton.uk

This fixed the problem for me, please could someone verify?

Google user: bernd.kilga

On my setup the patch at #17 doesn't send any keys to the client. No fix for me.
(I've recompiled it twice and checked the diff manually).

I'm not sure why it doesn't work for me.

Nick: This ticket also contains the unresolved sticky issue (a different one than
Issue #7

Please re-open.

Google user: nick.bolton.uk

bernd.kilga: Thanks for the speedy update. I'm sorry that this didn't fix your problem,
lets hope Ed has time to take another look.

Google user: edw...@carrel.org

Yeah. I'll be digging into this later on today.

bernd: are you still not getting any text event data sent to the client? I might need
to go back and construct something of a unified patch for all of this, and give a
revision for it to be applied against.

Google user: bernd.kilga

I've started synergyc with DEBUG1 and received no text event data. At the moment my
own patch (#3) is the only working solution for me. Feel free to poke me anytime on
Freenode (frame) for some quick testing.

Google user: nobleclem

quick run of the latest trunk synergys on the mac no transfers keys to the win client.

Google user: nick.bolton.uk

I've been getting this issue for a while... Every so often keyboard input stops working
on my Mac OS X (10.5.7) but mouse still works (UI is still responsive) - the fix is to
reboot my mac (restarting synergyc doesn't work).

Google user: nick.bolton.uk

I think this may possibly be caused by pressing Alt+Tab (instead of Windows+Tab), but
that could be completely inaccurate.

Google user: dplbird

i use synergy under 10.5 with XP as a client and vice versa with no problems? The
only problem I have is when using XP as a client, sometimes keystrokes dont work but
this is only when you have something selected in 10.5. ie, you have an icon selected
in OS X, cannot type in XP. If you de-select the icon in OS X you can type fine in XP.

Google user: jcaughel

I think I have seen this on occasion too though never when I have debug output
running -- always when I am just working. I usually find that the focus has been
stuck to a terminal window on the Mac OS X server and all of the input that I
expected to go the focused window on the client is actually getting entered on that
terminal window on the server. I will try to isolate this behavior and get more
detail on it.

Google user: edw...@carrel.org

@bernd.kilga: I didn't ask in my previous comment on here; did you combine
keystroke.patch with server_keyboard.patch? They complement one another, as opposed
to one obsoleting the other. I was hoping to avoid confusion by keeping them separate
so patch(1) didn't break horribly when someone with the first patch applied then
tried to apply the second. Apparently, I caused much unintended confusion anyway. *sigh*

-Missing comment-

Google user: bernd.kilga

Ignore my previous comment (deleted it). I'm not 100%% sure if I've compiled both
patches. I'll retry and report back.

InProgress ?

Google user: nick.bolton.uk

Google user: nick.bolton.uk

-Missing comment-

Google user: bernd.kilga

edw...@carrel.org: Tonight I've finally had time to retested comment #11 and can
confirm the following:

the timing based stickiness occurs if you apply both patches. I also asked Nick to
send me his current binary, and I was able to reproduce comment #11.

Google user: edw...@carrel.org

@bernd.kilga: Interesting. This stickiness seems oddly reminiscent of Issue #9 . I
wonder if they are both tickling the same bit of logic which causes the modifiers to
be stuck down. I wonder if this indicates that both this issue and that issue are
dependent on timing. That would be a royal pain, but it would seem a logical place to
start from, at least from the stand-point of Occam's Razor. :-)

Google user: bernd.kilga

I talked to nick yesterday on IRC and mentioned the following:

it's a theory mind you.. but I noticed the following for comment #11 which might also
be a factor for the big stick issue #7 :

when you enable debug2 you can monitor all activity between client and server.

if you hold down a key and don't lift it the log entries report multiple entries: up
down up down up down. I think that's how keyboard events are supposed to work. Now,
as for Issue #1: when you lift the key somewhere in between this cycle the key
remains sticky. this doesn't matter for single keys, but seems to cause problems with
modifiers. e.g. two keys.

Google user: bernd.kilga

typo in comment #36: issue #9 :)

Google user: aaronjlwebb

I have the same issue with the keyboard input "sticking" to a terminal window in OSX.
Here's some info:

• Latest synergy+ build (1.3.4) running as server on MBP with Snow Leopard (OSX
  10.6.1) via SynergyKM preference pane (I symlinked
  ~/Library/PreferencePanes/.../synergy* to the 1.3.4 binaries in /usr/bin/)

• Latest synergy+ build (1.3.4) running as client on Windows 7

• External monitor attached to the MBP, set up between the MBP and the Windows
  machine

• I have 2 Terminal windows open on the MBP - one on the external display, one on the
  main display.

• If either Terminal window has focus when I mouse onto the client, the Terminal on
  the main MBP display receives all keyboard events.

• If I open another window (e.g. Finder) on the external display and mouse onto the
  client, the Finder window receives all keyboard events
• If I open another window (e.g. Finder) on the MBP display and mouse onto the
  client, the client does indeed properly receive keyboard events
  (this was not the case until I installed the 1.3.4 binaries - before that I had to
  switch Spaces to get the keyboard to work)

Hopefully this helps! Let me know if you'd like any more info.

Google user: aaronjlwebb

Update from previous comment.

I forgot that I had used TinkerTool to select the "Terminal: Auto-activate windows by
mouse cursor" feature on my MBP. When I turned this feature off, my issue went away.

For anyone who might not know, all TinkerTool does is change config files to provide
access to built-in (but somewhat hidden) features of MacOSX. I.e., some others
reporting this issue (specifically jcaughel I would guess) may have the same Terminal
feature turned on even if they don't use TinkerTool in particular.

Google user: bernd.kilga

I've compiled the latest SVN build (re3v 242) and the increased key-stickiness is
still existing (see Comment #11)

Sorry for the bad news.

? InProgress

Google user: nick.bolton.uk

Hope someone can move this forward.

Google user: painweb

No joy for me. I downloaded the source today (05/Jan/10) assuming that it has all the
patches applied (am I wrong?). I have been running synergys on a Linux box (with an
apple USB keyboard attached) and use it to connect to a MacOS X 10.6 laptop. With the
old synergy (v1.3.1) this worked okay, but the command key didn't work when switching
to the mac. So I thought I'd give synergy+ a try.

Compiled okay on Linux machine (eventually), started properly. I installed the 1.3.4
dmg on the mac laptop - it sees the server and I can move the mouse into and out of
the window, but as soon as I try to type something on the mac laptop the mouse &
keyboard stops working on both machines - locking me out of the Linux machine
(synergy server) completely. I have to remote log in and kill X to get it back.

Are there crucial patches that I'm missing, or is synergys broken?

Google user: jason.e.reynolds

I just downloaded the svn today 1/8/10 and also was having problems with keys not
replicated to the client. I noticed this log:

"Synergy server requires accessibility API enabled. Please check the option for
\"Enable access for assistive devices\" in the Universal Access System Preferences
panel. Unintentional key-replication will occur until this is fixed."

Once I did that, the client was able to receive keys again. (ctrl/shift/etc are
still sticky - I think it might be a bug in onKey() )

-Missing comment-

Google user: nobleclem

Bingo that worked perfectly. Just built r343 and enabled the assistive devices
setting and the keyboard works.

Google user: racebee

I'm not 100%% sure my problem is being described here. It sounds like it is... I'm
using a Ubuntu 9.10 Server and OSX Snow Leopard client. The Keyboard input has the
stuck shift key issue from time to time and randomly letters get capitalised while
I'm typing. Is there some dev code I could run to help resolve this, and on which
side server or client?

(Note - I'm able to use the macbook with synergy-plus with less issues with Windows 7
(64-bit) as server. I have a few stuck shift issues, but no random capital letters.)

Google user: racebee

Update - Since my initial post I haven't had any repeat issues of the random
capitalisation. Maybe leaving the screen and re-entering reset something that was
causing this.

Thank you.

Google user: joshue

hi "/p/synergy-plus/source/detail?r=acebee":racebee , I'm having the exact same problem you describe. I'm running
synergy-plus 1.3.4 server on an XP PC and the synergyc is on OSX snow leopard (latest
version). This is happening fairly frequently for me, but it is intermittent and
doesn't seem to follow any kind of pattern.

Google user: edw...@carrel.org

Issue #9 for more about this sticky-key problem. It's
not a platform specific problem.

Google user: jzablot

ctrl+arrow keys use to stick for me with OS X 10.6.3 as client, Win 7 as server. Then
something broke and shift/alt/ctrl keys do not work when sent from the Windows box.
If I turn on debug2 level debugging I can see that the client seems to be receiving them.

Tried updating server and client to 1.3.5 RC and it makes no difference. Also tried
checking 'Enable access for assistive devices'. Not sure what broke this? OS X update
maybe?

-Missing comment-

Google user: misterblah

everything has been working for me, except holding the control key and clicking the mouse

if I use the osx keyboard viewer and compare an attached keyboard's control/command/option/shift input vs
synergy (windows host) the synergy server sends what looks like repeated clicking of the key, instead of a solid
holding down of the button

the keyboard viewer also freaks out after a while! not sure what is causing that

Google user: BostonVaulter

Is anyone still having this specific problem?

Testing it using an OSX 10.5 synergy-plus1.3.5 server and a Windows XP synergy-plus 1.3.5 client everything
seems to work okay. I can type fine from the server to the client and the modifier keys work fine. Haven't done
enough testing to ensure there isn't any sticky keys but that is beyond the scope of this issue.

Google user: jzablot

Yes it's still an issue for me on 1.3.5 RC with OS X 10.6 as described by myself
above. I have 10.5 installed as well so I can try going back to that to see if it's
still an issue.

Maybe I will try checking out the code and attempt to debug it. Anything specific I
should check seeing as most keys work for me, except a few like shift/alt?

Google user: medmex

yup i have the same problem.
10.6.3 server and ubuntu 10.04 client.

Google user: a...@awh.org

1.3.5RC with OS X 10.6 client and Windows 7 server is still not transmitting letters,
just arrows...

? 1.4.1

Google user: nick.bolton.uk

1.4.1 ?

Google user: nick.bolton.uk

Google user: aza...@carrel.org

Google user: klinebch

The last several reports have been around Mac OS X 10.6 as client. I'm running 1.3.5 as server, with Win7 and WinXP clients, and I fail to control keyboard on either of the clients at all (not sticky issues, simply no keyboard control at all).

Is anyone seeing this anymore with the latest builds? I'm successfully running 10.6.5 as a client w/ 1.5.0 r812 with Win7 running 1.3.6 r812 as the server. There are some input issues (e.g., #458, #2763), but my keyboard for the most part works.

?

Keyboard does not work with Mac OS X (10.5) as client Keyboard does not work on Mac OS X client

1.3.3

Mac OS X

QA for 1.3.6 showed that this is still a problem (cannot type stuff on client when server is osx), but some users report it working in trunk.

InProgress Accepted

1.3.7

Keyboard does not work on Mac OS X client Mac OS X server not sending keystrokes to client

Improved title and description.

Urgent Immediate

Also, previous comments seem to indicate that the patches do not fix the issue.

Oh wait,

Was 1.3.3 around the time when we went from using the floating window to using event taps?

If so, could this be related to not having the option set related to assistive devices in Universal Access pref pane? That would explain why some people are seeing thing working fine, and why the rest aren't seeing anything at all.

If that's the case, then what we would need to do is build in a check in MacOS for state of this switch, and then refuse to run if it isn't set. IIRC, this was discussed either earlier in this ticket or in another ticket.

Can other listeners on this ticket check this and see if it is a likely culprit.

I can confirm that with 1.3.6 that I can now properly use my keyboard after enabling assistive devices in the universal access pane.

@Dylan: thanks for the update.

@All: There's no indication about this being required at all anywhere on the site. There needs to be something, probably in large red letters right above the Mac download page, saying that this step needs to be done.

Or, maybe, we need to bring the old window driven movement capture mechanism back as a way of not requiring this option be set immediately. It isn't exactly clean, but it worked.

1.3.6 keystrokes are working for me using 10.6.4 OSX as server with XP SP 3 as a client (assisted devices enabled).
1.4.2 keystrokes they aren't.

I did a few more builds, up to at least r887 keystrokes work as expected for me.

Erik Meade wrote:

I did a few more builds, up to at least r887 keystrokes work as expected for me.

Is that trunk, or one of the branches?

The trunk yes. svn checkout -r 887 http://synergy-plus.googlecode.com/svn/trunk r887
Also I noticed no keystrokes when building from the 1.3 branch though.

is bug 517 a dupe of this? I am having this exact issue on 1.3.6 with osx 10.6.6 server and client.

synergy_57.patch - Peter Van der Beken 23 Feb 2011 11:38

I think there's something wrong in http://code.google.com/p/synergy-plus/source/diff?spec=svn889&r=889&format=side&path=/trunk/lib/platform/COSXKeyState.cpp

In particular this block:

        // choose action

        UInt16 action;

        switch (eventKind) {

        case kEventRawKeyDown:

            action = kUCKeyActionDown;

            break;  


    case kEventRawKeyRepeat:  
        action = kUCKeyActionAutoKey;  
        break;  

    default:  
        return 0;  
    }  

was added in the @if (layoutValid) {@ block. The @action@ variable that was added shadows an earlier one, and the switch compares the @eventKind@ variable to the wrong constants (@kEventRawKeyDown@/@kEventRawKeyRepeat@ vs @kCGEventKeyDown@). Removing this whole block fixes the keystrokes for me with a build from trunk on 10.6.6.

I'm attaching a patch, but I have no idea if this is the right fix. I might be missing why that block was added in the first place.

synergy_57_corrected.patch - Peter Van der Beken 23 Feb 2011 11:45

A small error crept into the previous patch, attaching corrected one.

I am facing the same issue with Synergy 1.4.2 on OS X 10.6.4. Using OS X as the server and 64-bit Linux as the client (running 1.4.2 on both).

For what it's worth, I'm having this exact problem. I tried on 1.3.x, 1.4.2, 1.5.0r911 on a Snow Leopard 10.6.6 server and a Ubuntu 10.10 client. Mouse works fine on the client, but typing just sends characters into whatever is in focus on the server.

There have been many posts on this issue over on the code.google.com repository (which should be shut down to updates to make more clear). Please take a look at the notes at http://code.google.com/p/synergy-plus/issues/detail?id=47. Basically, it's a bunch of folks confirming the issues with various versions of things, but all with Mac OS X as the server.

I am also experiencing the same problem with OS X as the server using version 1.4.2. Mouse works fine but no keyboard. Is there any indication on what is causing this and if it will be fixed, I see this has been an on going problem for a considerable amount of time.

Just to confirm that I've also had this issue with an OS X 10.6 server, with both 1.4.2 and the source checkout out from trunk just now. synergy57corrected.patch fixes the issue.

synergys-patched - Matthew Toso 24 Mar 2011 18:21

I had this same issue with an OSX 10.6 server and Win XP client. The synergy57corrected.patch fixed the problem. It took me awhile to patch and compile so I've attached the patched synergys binary as a convenience to others.

Accepted InProgress

49

@Peter: the fix looks correct, and it builds on my Mac. It looks like the business end of it is fixing the way the taps are created so that the tap placement doesn't use tap location constant. The changes to COSXKeyState look to just be removing dead code. Do I have this right?

If there are no objections, I'll commit this into trunk. Thanks for the patch.

Well, wait. I think I have this wrong.

The change to the tap creation is just using the proper constant, but the old constant has the same numerical value.

The real change is that the switch continually hits its default case and return 0, even though the action var is never used past the switch in the assignment. This makes a lot more sense, and is almost certainly the problem. The constant value for kCGEventKeyDown = 1. But the constant for kCGEventKeyDown = 10, which is what the tap would throw back if asked its type.

This is probably a big enough deal that we'll want to cut a point release just for this fix. There's not much people can do w/ Synergy without it.

Yeah, the first hunk is just using the right constant (which happens to have the same value). It's just a cosmetic change.
The action value is used later on (but removing this one is ok, because it shadows the one that should be used). We do indeed always hit the default in the switch and return early.

Matthew Toso - patched binary works for me (but only after I turned on accessibility options). Thanks!

Patch from Peter has been committed to tip and to the 1.4 branch. Thanks Peter.

It should end up in the nightlies by tomorrow, provided that they are still working.

Looks like the build farm needs some TLC...

http://buildbot.synergy-foss.org:8000/builders

I'll get right on that.

The same with MacOSX 10.6.7 as server, Windows 7 64b as Client

I have try with 1.4.2 r913 on Mac & Win
With root on Mac, and start the services as Admin on Windows.

When i start as root on Mac, the keypress do nothing, on the Mac and on Windows.

I recently attempted to upgrade my Mac OSX 10.6.6 synergy server to 1.4.2 from 1.3.4 and the keyboard stopped working using either a 1.3.4 or 1.4.2 synergy client on Win 7. I am hoping 1.4.3 will fix this issue, as I really starting to need clipboard sharing.

I notice this note above says:

Note: Fixed in 1.4 and trunk, but not in 1.3 -- this must be fixed for the 1.3.7 release, as it is fundamental behaviour.

Agree with Marco. This should be in 1.4.3 todos.

1.4.3 is now an internal release for improved testing. I have assigned this to 1.4.4 as it's the closest to the version you're requesting.

1.3.7 1.4.4

UPDATE
I may have found a workaround for the issue I'm experiencing described above. In an attempt to get a DEBUG log to attach to my report, I accidentally tried using an old keyboard shortcut I had set up to switch synergy contexts from server to client, Ctrl-Cmd-Left Arrow.

As soon as I did this, keystrokes started showing up on the client again. I have only seen this work once so I will leave another comment if this works as a fix for me consistently.

It's really hard to understand what the status of the fix for this bug is. It would appear that a fix has been checked in to some branch(es?) and a "fixed" binary is attached to this issue.

However, I am still experiencing this issue; after 1-5 hours of use, the Mac server stops sending keystrokes to the Windows client. I have not been able to determine if there is a specific action that triggers this event. I have had it happen to me 20+ times now but nothing stands out as the trigger.

I have seen the issue while using the following builds:
* the latest nightly builds from the 1.4 and 1.5 branches (both the April 3rd ones and then the ones from this week)
* I also tried the server binary that's attached to the issue here.
* Any official release binary

In conjunction with my setup...

• synergy server running on a MacBook Pro running OS X 10.6.7 (I should note that I did not experience this issue prior to upgrading from 10.6.6 to 10.6.7)
• synergy client runs on Windows XP SP3
• Configuration is straightforward, client on left server on right, set up and managed via QSynergy on the Mac server

Attempted fixes that do not work (these seem to help with other issues/bugs like the clipboard syncing stopping):
* Restart synergy client
* Restart synergy server
* Unplug and replug the USB keyboard on the server
* Kill the dock process
* Quit and restart every other application that was running (thinking that an app was somehow taking priority and stealing keystrokes from synergy)

Only Known "Fix"
The only way to get keystrokes sending to the client again is to log out of OS X and log back in again. This forces me to shut down all of my applications and start all up again.

Initially I was restarting but I tried logging out in an attempt to save time and it worked. I think this forces a restart of loginwindow or WindowServer?

Please, can someone clarify whether they are experiencing what I am seeing and if not, which version of the synergys binary they are running?

I am happy to do additional testing, provide DEBUG info, or answer any other questions to help in resolving this issue. It's seriously affecting my productivity.

The problem just happened again and what seemed to fix it last time did not work.

The one thing that I have noticed that seems to trigger the problem often (but not always) is the keyboard shortcut to Reply All in Outlook on Windows. Ctrl-Shift-R. This maps to the same modifier keys on my Mac so no difference there.

I am not sure why this key combo would trigger this issue but that's all I know.

I just attempted to run synergy on iMac OSX 10.6.7 (synergys) and a Windows 7 64bit PC (synergyc). The server runs fine and the client connects fine - the mouse seems to work correctly. I have not noticed any issues. However the keyboard is not working at all.

I would like to know if anyone has gotten this to work with any version - I have downloaded and tested both the 1.3.6 stable and the 1.4.2 beta. On both systems I used the binaries for each.

1.4.4 1.4.5

InProgress Accepted

49

1.4.5 1.3.8

Armen, going from the latest QA results, the bug still exists in 1.3.7 and 1.4.3 for OSX 10.5 and 10.6. The bug is assigned to the next 1.3 release, which means it'll also be fixed in the next 1.4 release.

Following up on Bug #2852: I am seeing this issue in 1.4.2 and 1.4.3. Version 1.3.4 continues to work for me. Some commenters have indicated that the keyboard does not work; in my case, keystrokes that should go to the Windows client are appearing on the Mac (server).

Latest version on OSX Lion still having the same issue, my setup is :
Mac OSX 10.7 and Win 7 64bits
Status:
- Mouse working OK
- Clipboard sharing working OK
- Keyboard sending only the direction arrows, other keys doesn't work.

I noticed trunk has an issue with sending correct modifiers to the client (at least when server is running on 10.7)
I attached a diff that hopefully fixes that;
Problem:
in COSXScreen.cpp,

CGEventFlags macMask = CGEventGetFlags(event);

...

KeyModifierMask newMask = m_keyState->mapModifiersFromOsxCarbon(macMask);  

osx_regression.diff - msft guy 22 Aug 2011 04:46

Is there a combination of Synergy versions where this problem is NOT present with a 10.7 (Lion) server and a Win7 client? I seem to remember keystrokes working fine with a previous setup of mine, but I can't for the life of me remember which versions were installed....

Knowing which ones work may give some clue as to how to fix this (since it's been a problem going on 2.5 years now)....

To answer my own question (and to confirm comment 99), v1.3.4 on the Mac OS server side seems to work (I'm also running v1.3.4 on the Win client side). I apologize for cluttering the issue space with this, but in case there were onlookers who might benefit, I thought I'd chime in.

I should note, I'm not running trunk on any machine (as of right now), so I can't confirm a fix there....

To add to #103/99, I downgraded Mac OS 10.6.8 server from 1.3.6 to 1.3.4 and it fixed the issue with Win7 (64) 1.3.6 client not receiving key strokes, I kept the Win7 client at the newer version. So the problem seems to be more on the server than the client version?

(Copy/paste not working but that's probably unrelated. Also the auto start for main system isn't running as the interactive user it seems it just threw the mouse back to the center of the server screen when I go to client, so I had to switch it to 'when I log in' auto start instead and that works. Will look into that more later)

Not sure if it's any help, but my current setup wasn't cut'n'pasting very well, so I tried installing 1.4.3 on the WinXP (as client) and MacOS X 10.6.8 (as server). This 'not sending keystrokes' issue was immediately apparent.

However, when I switched back to using version 1.3.1 for the server on the mac (installed via MacPorts) and continued with 1.4.3 on WinXP, keystrokes are sent fine, and I'm finding my clipboard problems have disappeared also.

Same thing is happening to me currently.

MacOSX 10.6.8 (as server)
MacOSX 10.6.8 (as client)

Synergy1.4.4 running on both. (synergy-1.4.4-MacOSX106-Universal). No keystrokes are appearing on the client, but appear on the server instead.

I tried reverting to synergy-1.3.7-MacOSX106-Universal on the server as an experiment per Mark's suggestion since it seems to have worked for him, but with no luck. In that scenario the 1.3.7 server won't allow me over onto the 1.4.4 client at all.

Yuri Green wrote:

Same thing is happening to me currently.

MacOSX 10.6.8 (as server)
MacOSX 10.6.8 (as client)

Synergy1.4.4 running on both. (synergy-1.4.4-MacOSX106-Universal). No keystrokes are appearing on the client, but appear on the server instead.

I tried reverting to synergy-1.3.7-MacOSX106-Universal on the server as an experiment per Mark's suggestion since it seems to have worked for him, but with no luck. In that scenario the 1.3.7 server won't allow me over onto the 1.4.4 client at all.

Problem solved!

After examining the log at Info level, and selecting "Enable access for assistive devices" in System Preferences -> Universal Access my original problem is totally fixed. This really needs to be added to the installation instructions, the wiki, QSynergy startup messaging, everywhere essentially. :-)

Another report:

Server: Mac OS X 10.6.8 (10K549) on a Al MackBook Pro 15". Assistive devices support enabled in settings.
Client: Windows 7 Pro.

Version: 1.4.4 Beta (server and client) d/l 29th Sep 11. Mouse works perfectly. Lower case letters only sent to client, pressing shift stopped any key presses being sent. Alt and other special keys produced inconsistent behaviour.

Version 1.3.7 Stable (server and client, 64 bit on OS X) d/l 30th Sep 11. Mouse works perfectly. No key presses at all sent to client. Debug shows that key presses are detected on server, but never sent to the client. (Plenty of 'event' lines, no 'send key' lines.)

Version 1.3.1 (server, 32 bit on OS X), Version 1.3.7 Stable (client) d/l 39th Sep 11. Mouse works perfectly. Keyboard appears to work perfectly.

Not tested: 32 bit version of 1.3.7

WRT to num. 108 it might be worth noting that I was using the same synergy.conf for all tests. Nothing special about the config, apart from swapping super and alt. Removing the key swap had no effect on the tests.

Running Mac OS X 10.7.1 on both client and server. Only rolling both client and server back to 1.3.1 fixes this issue for me.

Running Mac OS X 10.7.1 as server, Windows 7 x64 as client. Downloaded nightly build synergy-1.5.0-r1094-MacOSX104-Universal.zip for server, synergy-1.5.0-r1094-Windows-X64.exe for client. Mouse and Keyboard are functioning. Though copying text between the computers doesn't seem to work.

C N wrote:

Running Mac OS X 10.7.1 as server, Windows 7 x64 as client. Downloaded nightly build synergy-1.5.0-r1094-MacOSX104-Universal.zip for server, synergy-1.5.0-r1094-Windows-X64.exe for client. Mouse and Keyboard are functioning. Though copying text between the computers doesn't seem to work.

However, still unable to use modifiers (can't hold shift to make a capital letters, ctrl-c ctrl-v, etc.).

Brennon Bortz wrote:

Running Mac OS X 10.7.1 on both client and server. Only rolling both client and server back to 1.3.1 fixes this issue for me.

Thanks Brennon, I was running 1.4.4 on both the Mac 10.7.1 and Windows XP sides, and had all the keyboard modifier problems when Mac was acting as server. Rolled back to 1.3.1 on both client and server and keyboard modifiers are working again.

(BTW, thanks to the synergy team for a great piece of software)

1.3.8 ?

Well, that's unfortunate. By the way, the notes say that this is fixed in 1.4 and in the trunk. This issue is most definitely present in both of those, as well. Regression bites... Thanks for your work, either way.

Updated issue notes; this will be fixed in both 1.3 and 1.4.

I like to add that on lion as server and win7 x64 as client latest version working is 1.3.6. after that changes were made having the keyboard issue(s). 1.3.6 is working properly here. since beta 1.4.5 keyboard is working a bit but ctrl, shift, alt, cmd are corrupt as already reported.

Server: Mac OS X 10.6.8 German keyboard ("Enable access for assistive devices" enabled)
Client: Mac OS X 10.7.2 UK keyboard

Running 1.4.5 Beta on both - Mouse fine. Server only sends lowercase keys to client. Random characters if I use shift. Copy/Paste doesn't work properly.
Running 1.3.1 Stable on both - Everything working fine including copy/paste.

I have three machines.
PPC OSX-10.4 with synergy 1.3.8
Intel OS X 10.6 with synergy 1.3.8
FreeBSD with synergy 1.3.6

FreeBSD only has a package for 1.3.6 at this time so I'm stuck with the 1.3 series.

With OS X 10.4 as server the mouse cursor goes WILD on the clients.. (bug 2963) so I can;t use it that way.
which is a bummer because that's my usual keyboard/working machine.
(Does exactly the same thing with the downloaded 1.4.5 dmg BTW, though there doesn't seem to be a bug for that against 1.4 series (though you export a dmg, I guess you haven't tried it as server?)

If I make the 10.6 machine the master then I cannot type to either of the other machines (this bug)
Though the mouse works fine, I can only send non alpha keys (e.g. cursor up or cursor down and function keys) to them.
If I make the FreeBSD machine the master, the mouse is great everywhere and I can only type to the OX X 10.6 machine but when I type to the 10.4 machine I can only send cursor commands and function keys again.

Same problem here!

Server : synergy 1.3.8 on Mac OSX 10.7.2

Client is either:
- synergy 1.3.1 on Mac OSX 10.6.8
- synergy 1.3.8 on Mac OSX 10.6.8

IMHO the 1.3.8 should not be called "stable"
bump!

Tilo S wrote:

Same problem here!

sorry, forgot to mention that I have "Enable access for assistive devices" both enabled or both disabled on Client/Server
... neither works

Server : synergy 1.3.8 on Mac OSX 10.7.2

Client is either:
- synergy 1.3.1 on Mac OSX 10.6.8
- synergy 1.3.8 on Mac OSX 10.6.8

IMHO the 1.3.8 should not be called "stable"
bump!

Tilo S wrote:

Same problem here!

sorry, forgot to mention that I have "Enable access for assistive devices" both enabled or both disabled on Client/Server
... neither works

Server : synergy 1.3.8 on Mac OSX 10.7.2

Client is either:
- synergy 1.3.1 on Mac OSX 10.6.8
- synergy 1.3.8 on Mac OSX 10.6.8

IMHO the 1.3.8 should not be called "stable"
bump!

I have this same problem with a Mac OS 10.7 server and an Ubuntu 11.10 client. It occurs both when the server and client are 1.3.8 and when they are 1.4.5.

Hello all...same issue here.

Synergy Server (1.4.5) setup on Mac OS X 10.7.2 and the Synergy Client (1.4.5) is running on Windows XP SP3.
The mouse moves fine between the two systems. Typing works correctly in Text Editor on the Server.
When I move the mouse to the Client and attempt to type, the typing continues to appear in Text Editor on the Server.

I am trying so hard to apply one of these patches but there is no such directory as /src/lib on my Mac (Running OSX 10.7.2).

Help!?

solved by accessibility api be enabled works like a charm now on all lion i have as server 1.4.5 1.4.6

Confirmed on Mac OS X 10.7.2 (server) + Windows 7 32-bit (client). Fails both with 1.3.8 and 1.4.5.

? 1.4.6

Accepted GotPatch

GotPatch Accepted

Hi guys, I was hoping to apply a patch from this issue and get the bug fixed for the 1.4 release this weekend. Unfortunately though, it looks like the patches have already been applied to 1.4 but do not solve the problem. I have tried to solve the issue myself, but it seems that @COSXScreen::handleCGInputEvent@ never gets called and I'm not entirely sure why not. I've had to delay this fix until the next release (March) -- that is, unless someone provide a patch before this weekend?

1.4.6 1.4.8

It would be nice if this got fixed. Makes software unusable.

Immediate High

I really hope that this bug will be fixed in newer version.
Environment: client win 7, server mac os x lion
I tried on 1.4.X and 1.3.X
Mac version 1.3.8 server send to client only OPTION(alt) key and where it works like WIN button.

I really hope this gets fixed. I'm still having this problem. Only my arrow keys and parts of the numpad work on the client.

Host: Mac OS X 10.7.3 (1.3.x)
Client: Ubuntu 11.10 (1.3.x)

I've also tried using 1.4.x.

+1 vote for getting this fixed. It impacts me every day.
:D

Stefan Sobering wrote:

I really hope this gets fixed. I'm still having this problem. Only my arrow keys and parts of the numpad work on the client.

1.4.8 1.4.9

+1 vote for getting this fixed.

I've even tried the 1.4.8 nightly and it nearly works but the right-click hold move camera function still doesnt work in WoW ... so I guess it's not quite ready.
I use this for gaming and work with three Macs, so I really would love to see this working.

I'm also conscious that someone is working away on this and I am benefiting for free - is there anywhere to make a contribution when the Mac Server is working again ?

I installed 1.4.8 10.7 tonight on two 10.7 macs and at least simple key presses are working for me! One of my favorite commands Ctl+r, which prints the copyright symbol rather than starting backwards command search) seems to set the client into another text mode. Another Ctl+r doesn't disable it, though moving the mouse out of and then back into the client screen does.

@Jonathan Cox I don't know about specific to this fix, but there is a donation link on the home page. I just kicked in a few bucks as last time I tried not even this much was working yet. There is an extra instructions text box you could request more effort on this issue.

Ack, no edit? Should have been 1.4.7 not 1.4.8. Sorry.

The 1.4.8 Build doesn't work either the only key that goes over to the PC (Windows 7) Is the Windows key. The mouse goes over fine. In the log on the mac hosting the keyboard and mouse it says the following:

starting server
config file: /var/folders/5d/crqmv8jd0n14bqz2c1cw3hsrnnl2yl/T/qt_temp.ux2739
log level: NOTE
WARNING: mac accessibility api is not enabled *Would Like to know what this is referring to*.
NOTE: started server, waiting for clients
NOTE: accepted client connection
NOTE: client "lhreukd1-ws402" has connected
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]
NOTE: Ignoring Out of Bounds Quartz Event type: 0x1d [max 0x1c]

Hope that helps. :).

synergy-1.4.8-r1283-MacOSX107-x86_64 with both client and server on OSX 10.7 is much better than on 1.4.7 many (all?) of the keyboard related problems seem gone for mac to mac. Thanks!

Very strange. I'v tried version 1.4.8 but it still havn't worked... Only Alt and Shuft buttons works fine...

Just another data point - the below seems to be working fine for me (once "Enable access for assistive devices" was turned on - see posting #43 above)
Note that neither 1.4.7 beta server nor 1.3.8 stable sent any keyboard input to the client. Also, 1.4.8-r1283 did not send keyboard input until I enables assistive devices.

Server: synergy-1.4.8-r1283-MacOSX104-Universal.dmg on OS X 10.7.3 ("Lion")
Client: synergy-1.3.1-6ubuntu1 on Ubuntu 10.04.3 LTS

Q

r1328 -- I just committed a risky bit of code to see if this will force users to configure their system correctly. The Mac build is totally broken right now as I'm busy rummaging around in the Windows code... Should be fixed soon though.

BUMP, this is a killer issue.

I can confirm it doesn't work with the latest everything, Synergy 1.3.8 or 1.4.8 in Lion 10.7.3 as server connecting to Ubuntu 11.10.

Any updates?

Tyler Brock wrote:

I can confirm it doesn't work with the latest everything, Synergy 1.3.8 or 1.4.8 in Lion 10.7.3 as server connecting to Ubuntu 11.10.

Are you sure you're using 1.4.8? This version will not allow you to start without enabling "assistive devices". If you have this enabled, it should fix the issue (at least, it does for me).

Nick Bolton wrote:

Tyler Brock wrote:

I can confirm it doesn't work with the latest everything, Synergy 1.3.8 or 1.4.8 in Lion 10.7.3 as server connecting to Ubuntu 11.10.

Are you sure you're using 1.4.8? This version will not allow you to start without enabling "assistive devices". If you have this enabled, it should fix the issue (at least, it does for me).

Nick, I currently see two issues with 1.4.7. Indeed the assistive devices is required for any keyboard events to get routed, so good to hear that's been addressed in 1.4.8. However, on OS X 10.7.3 I still see a problem with the keystrokes being misinterpreted in COSXKeyState::mapModifiersFromOSX(UInt32 mask). Perhaps this second issue is what Tyler is seeing in 1.4.8?

I'll see if this issue has another bug associated with it, but I have a patch work-around that works for me. Now that I see this bug, I notice my patch looks very similar to the patch "msft guy" posted a while back.

On my setup Synergy 1.3.4 (yeah REAL OLD) is what I've been using on OS X 10.6.8 for the server, and 1.3.7 on the client (fedora 16).

I just tried 1.3.8 and it exhibits the behavior in this bug. 1.4.8, however "seems" to work fine.. (though I don't like the synergy icon appearing in the doc for the synergys process!!)

Accepted Fixed

Hello,

Can anyone tell if this fix has been released in any nightly build? Or when it will be introduced in a build?

Look forward to seeing this one fixed and regressed :)

Thanks,
George

See my comment #144 above. issue #57#note-144 I've successfully used several daily builds since then (no problems with any that I've tried).

I have the same problem.

synergys on OSX 10.7.4 doesn't send keyboard to synergyc on OSX 10.7.4 (using the nightly build version of 1.4.9). I've also tried 1.4.8 with no luck.

Did you "Enable access for assistive devices" as per #144 above?

I was able to use the latest version of QuickSynergy with Lion 10.7.4, which ships with version 1.3.1 of synergy:

~ root# /Applications/QuickSynergy.app/Contents/Resources/synergys --version
synergys 1.3.1, protocol version 1.3
Copyright (C) 2002 Chris Schoeneman

I had to use a 1.3 synergyc client in order for it to work.

I read all of the above comments and, I think, I applied all of the solutions.
I enabled "access for assistive devices" and tried with the following build versions:
Server:
synergy-1.4.8-r1283-MacOSX104-Universal.dmg
synergy-1.4.8-r1283-MacOSX107-x8664.dmg
synergy-1.4.9-r1432-MacOSX107-x8664.dmg
synergy-1.4.9-r1420-MacOSX107-x86_64.dmg
synergys 1.3.1
Clients:
The same versions as above but for Windows x64

And I still cannot send keystrokes from my Mac OS server to my Win client.

I am running the following setup:
Server: Mac OS X Lion 10.7.4
Client: Win 7 x 64

Does anyone have any thoughts?

I tried various version of 1.3.7-1.4.8 with MacOSX 10.6.8 as server and Ubuntu 10.0.4 LTS as client trying to get my accented keyboard behaviour correctly but failed, currently 1.4.8 on both sides. I am also getting
NOTE: Ignoring Out of Bounds Quartz Event type: 0xfffffffe [max 0x1c]
and the client becomes inaccessible (i.e. can't move the mouse there until I restart the server).
Also, the keystroke for Alt and AltGr is unusable with my setup (accented keyboard), since left Alt is ok, but right Alt is also Alt. Remapping with: server:
meta = alt
client:
alt = altgr
gives me AltGr but looses Alt on the client. Can I have "rightalt=altgr" please :) AltGr is required to type \ and @ for example, Alt is required for lot's of menu functions, it's a bit difficult to have one or the other.

Confirming does not work with 1.4.8 Will try with 1.3.1

Server: Mac OS X Lion 10.7.4 Client: Win 7 x 64

It does not work for me also. Mouse is working, keyboard not.

Windows 7 x64 with synergy client 1.4.9 + Mac OS 10.7.4 with synergy server 1.4.9

"Enable access for assistive devices" is enabled on the mac.

Tried a few older combinations but have not found a working combination yet.

synergy-1.4.10-MacOSX108-x86_64.dmg fixed it for me!

Dunno if it's because of the synergy-1.4.10 or because of the MacOSX 10.8

Thanks! Worth a donation.

I just started experiencing this issue. As far as I can tell, the only way to fix it (temporarily) is to restart the server (mac).

I just upgraded to version 1.4.10 and OSX 10.8, and it started happening shortly after that.

Im using OSX 10.8 as the server and Synergy 1.4.10 and the keyboard still doesnt work. Doesnt even log any keyboard actions when in debug mode. Mouse works fine as usual.

Nevermind, rebooting fixed the issue with the keyboard. Weird that rebooting was required.

I'm using as well 10.8.2 and I can confirm the same as Mark Chaney, if you type anything in the client nothing gets logged and after the reboot it works again but after a while the same issue re-occurs.

I have to add that mouse movements and clicks does work ok on client, it just only keyboard

Confirming repro with this configuration:

Server: Mac OS X 10.8.2 [synergy 1.4.10] Client: Windows 7 x64 SP1 [synergy 1.4.10] Service, Elevate

After rebooting windows, I can use synergy to login (both mouse and keyboard function). However, after login, the keyboard no longer functions (mouse still works). Additionally, UAC prevents mouse from working.

This needs to be reopened. Happening with 1.4.10 beta - OS X as server, Windows Server 2008 as client.

the newest version: 1.4.10 beta - OS X10.8.1 as server, Windows 7 Home as client. Mouse works, but the keyboard no longer work. After i switch to use windows as server and OSX as client, it works!

Just adding my two bits..

Server: Mac OS X 10.8.2 running Synergy 1.4.10 Client: Windows 7 x64 running Synergy 1.4.10

Keyboard works fine, keyboard doesn't: alphabetical keystrokes are sent the Mac OS computer. Ctrl, Windows and Alt keystrokes are sent correctly.

I'm facing this same problem - mouse works and keyboard doesn't. Syenergy 1.4.10, both server and client are running OS X 10.7.5 .

(retyping as comment seems to have gotten lost)...

Same problem here on a pair of iMacs. One is running 10.78.5, the other is running 10.8.3. Mouse and clicks work fine, but keyboard never switches over to the other computer. Doesn't matter which machine is the Server, same thing happens either way, which I did not expect. Synergy 1.4.10 on both machines.

Confirmed not working for me, either.

Server: Mac OS X 10.8.3, Synergy 1.4.11 Client: Mac OS X 10.7.5, Synergy 1.4.11 Client: Windows 7, Synergy 1.4.11

Mouse works as expected. When typing on a client, focus switches back to the server after a few keystrokes. At this time, the mouse also appears in the center of the server screen. Seems more likely to happen when I type quickly. For example, I typed the letter 'd' about once every two seconds and got about 20 out. Then I sped up to a few per second and focus quickly switched to the server. I then tried typing random letters on the client at a rate of a few per second. Worked for maybe a hundred characters, then focus switched.

Same thing happens if I switch the client and server Macs, leaving the Windows 7 machine as a client. I have not tried with Windows as the server.

Same thing is happening to me.

Server: MAC OS X 10.8.3, Synergy 1.4.12 ("Enable access for assistive devices" enabled) Client: Windows 8 64bit, Synergy 1.4.12 (tried both 64bit and 32bit)

I had Synergy 1.4.10, it was working fine until this issue started happening. Upgraded to 1.4.12 but the issue remains. Mouse is working, but keyboard is not. Actually the only key that seems to work is the Window/Command key, No other keys are sent to the client but instead are still working on the server.