event loop model. Streams, stream filters, and sockets are
converted. Client proxies are almost converted. CServer is
in progress. Removed all HTTP code. Haven't converted the
necessary win32 arch stuff.
is ignored on that client (it has no effect on the server). This
is useful for keyboards that don't have separate number pads and
the user often uses the client's keyboard directly, when turning
on NumLock interferes with normal typing.
true, faking a mouse motion outside screen 0 is clamped onto screen 0.
When the workaround is enabled, we use XWarpPointer() instead of an
XTest fake motion. This isn't perfect but the only real fix requires
patching XTest.
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).
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.
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.
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.
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.
