key handling to win32 on both client and server. It also changes
the protocol and adds code to ensure every key pressed also gets
released and that that doesn't get confused when the KeyID for
the press is different from the KeyID of the release (or repeat).
screen saver from activating. It was unnecessary since the built-in
screen saver is disabled as appropriate; this call was just to
ensure that the screen saver wouldn't start if an external program
reactivated the screen saver after synergy disabled it.
It's possible that this was causing screen flicker under gnome, though
i don't know why. It's also possible that periodically sending events
to xscreensaver is causing the flicker but removing that code is more
difficult because xscreensaver can't be disabled, only deactivated or
killed.
events to other hook functions, which broke some tools like objectbar.
Second, windows key processing was fixed. Previously pressing and
release the key would only send a press event, locking the user onto
the client window; also, the win32 server treated as a Meta modifier
instead of a Super modifier, which broke any use of it as any kind of
modifier key. Third, added hacks to support several key combinations
on windows 95/98/me that are treated specially by windows, including
Alt+Tab, Alt+Shift+Tab, Alt+Esc, Alt+Shift+Esc, Ctrl+Esc, and any
combination using the windows key like Win+E and Win+F but not
Ctrl+Alt+Del. Fourth, scroll lock only locking to the client (which
only happened when using a synergy server on windows) has been fixed;
unfortunately the solution causes a lot of screen redraws for some
reason. Finally, there's been a fix to clipboard handling that may
or may not fix a problem where the clipboard would stop transferring
between systems after a little while. I can't be sure if it fixes
the problem because I can't reproduce the problem.
entering the loop waiting for it to deactivate. The failure
to check was causing the screen saver code to kick in when
the screen saver timeout occurred, even if the screen saver
wasn't enabled (because Windows still sends the screen saver
activating message for no good reason when the screen saver
is disabled).
when not on the primary monitor. This should eliminate the flicker
between virtual display 0,0 and the correct position. While this
allows the user to confuse synergy by using the client's mouse,
synergy recovers quickly and easily from any confusion.
a race condition where the synergy server updates the mouse
position but the synergy hook later receives a mouse update from
before the position change (i.e. out of order).
use Xlib to convert an unmatched keysym to upper and lower case and
use whichever, if any, is not the same as the original keysym.
This supports case conversion in any language that Xlib supports
it in.
mouse behavior on multimonitor windows systems. Those errors
broke synergy on all windows systems running as a server.
Also added an attempt to reduce the occasional jump that can
occur when switching screens when windows is the server.
code in a conditional for moving left that blew an assert verifying
that the mouse position was really on the screen if the neighbor
screen wasn't connected.
After that was fixed there was another problem when one screen
linked to another which then linked (in the same direction) to
itself. If the latter screen wasn't connected then it'd get into
an infinite loop.
It was doing that already if started through synergy but not if
started by something outside of synergy. In particular, if you
use `xscreensaver-command --activate' synergy used to send fake
mouse motion events every 5 seconds to deactivate it. That's
unlikely to be what the user wanted, especially if the locking is
enabled since it would force the password dialog to appear.
As before, it's recommended that client screens not use locking
because xscreensaver will not deactivate without getting a
password even if we make the request through a programmatic
interface. Presumably that's for security reasons but it makes
life harder for synergy.
reported by the synergy hook dll is in a space with 0,0 in the
upper-left which is not necessarily the same as the virtual desktop
space. So the windows primary screen now accounts for that. On
the secondary screen, mouse_event() doesn't seem to accept negative
coordinates even on the windows NT family, making monitors with
negative coordinates inaccessible via absolute moves. So if the
move will be to negative coordinates, use the windows 95 family
fallback of absolute moving to 0,0 then relative moving to the
final position.
and the platform specific implementations to lib/platform.
Added an lib/arch method to query the platform's native wide
character encoding and changed CUnicode to use it. All
platform dependent code is now in lib/arch, lib/platform,
and the programs under cmd. Also added more documentation.
lib/arch. This should make porting easier. Will probably
continue to refactor a little more, moving platform dependent
event handling stuff into lib/platform.
and sending those options to the appropriate client screens.
Currently, two options are supported: halfDuplexCapsLock and
halfDuplexNumLock mark the caps lock and num lock keys,
respectively, as being half-duplex.
the mouse is locked to the screen. We can't tell if a half-
duplex key is physically down and logically down just means
it's active so there's no point in letting it lock the mouse
to the screen.
their state when the screen was entered. Previously when
leaving a client screen the toggle keys kept their state so,
say, caps lock, would remain on. This was inconvenient if
you then used the client's keyboard directly.
from a windows server. Was converting ctrl+alt on windows to
mode switch on the server. No longer doing that; windows clients
will interpret ctrl+alt as AltGr and other clients will just see
ctrl+alt. Also made the right alt key mode switch on windows
servers in case the user wants to force a mode switch, but that
means the right alt key no longer acts as alt on clients.
an internal compiler error; building that file without
optimization works around the compiler bug. Sadly, synergy can
only interact with X windows, not native MacOS windows.
handling read errors at all and error handling for writes was
never being used. Now the socket disconnects if a read or write
fails on the socket for any reason except EINTR. Also added
<netinet/in.h> to includes in CNetwork.h because it's needed on
some platforms.
anyway but isn't implemented in winsock, removed use of INADDR_NONE
which some platforms don't define except on winsock which does
define it, and changed SOL_TCP to IPPROTO_TCP which should work on
more platforms.
more robust now. Also added handling of Super modifier key and
changed windows keys to map to Super instead of Meta, which is
the default on my keyboard.
Made extensive changes to the launcher to provide more control
over setting up auto-start and it now saves configuration to
the user's documents directory if auto-starting at login and
saves to the system directory if auto-starting at boot.
Replaced MapVirtualKey() with table lookup to work around that
function's lack of support for extended keyboard scan codes.
Added first cut at support for AltGr.
warp the mouse to the primary screen. entering the primary
screen causes the primary screen's window to be hidden. the
deadlock occurs because hiding the window seems to post a
message then wait for it to be handled (or possibly it won't
send a message while a posted message is being handled).
thread A locks the mutex, warps the mouse, the hides the window.
thread B begins processing the mouse warp then tries to lock
the mutex. thread A is waiting on the event loop owned by B
while B is waiting on the mutex owned by A. this fix simply
hides the window asynchronously. however, there may be other
ways to cause a similar deadlock that have not been found.
from config.h if available (which means version is now a
string, not three integers). Changed version to 1.0.0 and
protocol version to 1.0. And added MAINTAINERCLEANFILES
to makefiles to remove generated files.
would fail to open in such a way that it could never succeed
but it'd never stop retrying. now terminating when open fails
such that it'll never succeed.
synergy.cpp and server.cpp into cmd/synergyd as synergyd.cpp.
Moved and renamed related files. Moved remaining source files
into lib/.... Modified and added makefiles as appropriate.
Result is that library files are under lib with each library
in its own directory and program files are under cmd with each
command in its own directory.
crs