You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #1431: Synergy volume commands get "stuck"

Kind bug
Product Synergy
When Created , updated
Status closed
Reporter anonymous
Tags no tags

Description

I have Synergy set to use a hotkey for raising and lowering the iTunes volume. Quite often, if I use the hotkey to change the iTunes volume, there will be a lag of several seconds before the command is actually issued, and it becomes "stuck", continually raising the volume to the maximum (if I tried to raise it) or lowering it to the minimum. It persists even if I change the volume manually in iTunes; the only way to stop it is to issue another hotkey command to Synergy. This happens even if the hotkey is only pressed once, and it seems to happen most often when iTunes is busy at the time of the hotkey press.

I have tried changing the hotkey setting in Synergy and the problem persists; this has been a problem since version 3 (the first version I have used) and with both iTunes 8 and 9. I am on a MacBook Pro 3,1 running Snow Leopard 10.6.1. If any additional information would be helpful, please let me know!

Comments

  1. Greg Hurrell

    This is a glitch which happens only in Snow Leopard, and a partial workaround is already implemented. See ticket #1383 for the original discussion.

    The short version: for some unknown reason, Snow Leopard sends "key press" events reliably, but the corresponding "key release" events are sometimes dropped on the floor. Synergy never receives these events so there's not much it can do about them.

    The workaround that I implemented was to at least check for such missing events the next time the volume hot keys are pressed; there's no way for this to happen automatically because by definition you are not going to get notified of a missing event, but you can at least deduce at sometimes that you must have missed on an event.

    In practice this means that if you are using a recent version of Synergy then you can "unstick" stuck keys by using them again (ie. "volume up" gets stuck, you can "unstick" it by tapping either "volume up" or "volume down").

    I wish there was a way to really fix this instead of just working around it, but the actual cause of the problem seems to be outside of Synergy (something new and unknown in Snow Leopard) so it is difficult to tackle.

    I guess one way in which the current workaround could be improved would be to add a timer-based check as well. That is, not just check for missing events the next time the user presses a key combination, but actively check for them after a set time interval as well. eg. User press "volume up"; if we still haven't received the "key release" event after, say, 1 second then assume that the system has likely dropped the event on the floor and act accordingly.

    That might be a better workaround while we wait and hope for an Apple fix.

    Another possibility is looking at switching to a different API; I'm not even sure if exactly what the alternatives are under Snow Leoapard, but I will look into them.

  2. scott

    Thanks... just wanted to add my experience with this... I'm having the same problem. I've got my Synergy "volume up" keyboard shortcut set to "command UpArrow", and my Synergy "volume down" keyboard shortcut set to "command DownArrow". So, I've got Synergy set to use the EXACT SAME keyboard shortcuts that iTunes natively uses on its own. Not sure if that is what's causing the problem or not, but I just wanted to throw that out there in case it sheds any light on the problem. But yes, I am having the same problem in Snow Leopard and Synergy 4.2.

    Thanks.

  3. anonymous

    I was checking if other people have the same problems with Snow Leopard somehow not sending all keyboard events, and came across this message: http://lists.apple.com/archives/quartz-dev/2009/Oct/msg00085.html , which to me sound somewhat relevant. What he wrote was:

    Okay, I think I managed to find the cause of my problem. It turns out that it didn't have to do with the method I was using to post keyboard events, but rather a stupid programming error in my code that caused my function to intentionally post the kCGEventFlagsChanged events to a single application while posting the keystrokes to kCGSessionEventTap. Obviously that would cause problems. Apparently something about the events subsystem in OS X 10.5.X didn't cause this error to be an issue. But I've fixed it and things seem to be working normally again in Snow Leopard. Hopefully I've fixed it for good.

    I'm not sure if this has anything to do with the problem we are experiencing, but just thought I'd mention it.

  4. Greg Hurrell

    Nice try, thanks for adding the info, but it is unlikely to have any connection with the Synergy issue. The post you reference is talking about Quartz APIs and Synergy doesn't use those for hot key support; it uses a Carbon API instead.

    As I mentioned in my original comment, however, switching to another API is something which might work and I am going to investigate whether it is possible to do so.

  5. Greg Hurrell

    Just release version 4.2.1b which definitively works around this bug by removing the "press and hold" functionality from the volume hot keys.

    While this is strictly speaking a loss of functionality, it is at least a surefire way to eliminate the bug.

    I looked at switching APIs and it does not look to be viable at this point in time. I also did extensive testing to re-confirm beyond all doubt that the system is not sending "release" events for some key presses. The behaviour is totally erratic, unpredictable and outside of the control of Synergy.

    So for now this looks to be the only way to handle it. I'll be keeping an eye on whether Apple provides a fix for the release events which get dropped on the floor, and also for any API developments which might make switching feasible.

    In the meantime marking this one as closed.

  6. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
Add a comment

Comments are now closed for this issue.

Menu