non-blocking connect is available for writing (i.e. the connection
was successful) when the connection has actually failed. This
caused synergy to rapidly retry connecting. This change makes
synergy check for a connection error whether one was reported or
not. Thankfully, OS X does correctly set the socket error state
when it bogusly reports a successful connection so we can tell the
connection failed.
a synergy client on that OS and pointed it at a system that wasn't
listening for connections then instead of the connection attempt
failing with 'connection refused' the system would claim the
connection succeeded. A subsequent read would reveal the problem
and synergy would "disconnect" and retry, causing the CPU to spin.
The system does correctly set the socket error state so this
workaround checks for socket errors when connecting whether or not
select reports an error state.
Also, sometimes the system doesn't claim success but doesn't report
an error. Synergy eventually times out these attempts.
detect synergy hotkeys but a design flaw in X11 makes it problematic
with many applications. We'll have to fall back to the more
traditional XGrabKey when the time comes.
return 0 when O_NDELAY is set and there is nothing to read. We
want the O_NONBLOCK behavior where read returns -1 and sets
errno to EAGAIN when there is nothing to read.
that to the client. If it did then the user could see the effect of
ctrl+alt+del on both the server and client which we never want. The
user can use ctrl+alt+pause to emulate ctrl+alt+del on the client.
the X11 display connection. The only problematic method was
CXWindowsEventQueueBuffer::addEvent given that the other event queue
methods are only called from the main thread.
on a secondary screen when there's no physical mouse attached to
the system. Kinda flaky when a mouse is attached or detached but
seems to work well enough when the device is not attached to start
with and not attached while running synergy.
and on a secondary screen and locked to the screen (via scroll lock)
mouse motion is sent as motion deltas. When true and scroll lock
is toggled off the mouse is warped to the secondary screen's center
so the server knows where it is. This option is intended to support
games and other programs that repeatedly warp the mouse to the center
of the screen. This change adds general and X11 support but not
win32. The option name is "relativeMouseMoves".
didn't support them and the emulated versions were just as good
except for a performance problem with excessive locking and
unlocking of a mutex. So this also changes IArchString to
provide string rather than character conversion so we can lock
the mutex once per string rather than once per character.
multiple systems with automake, with X Windows and Carbon window
system APIs supported. It's also a starting port for supporting
win32 builds using mingw. OS X support is incomplete; the tree
will compile and link but the binaries will not function.
in use. The client was being correctly rejected but the already
connected client was being forcefully disconnected too because the
client to disconnect was found by looking up the client by name.
We now instead look up the client by IClient*.
The low-level hook can report mouse positions outside the boundaries
of the screen and bogus retrograde motion. This messes up switch on
double tap. This change attempts to detect and suppress the bogus
events.
crs