After shift+F11, both in Windows 7 and xp clients, WM_KEYUP events were missing for
SHIFT and F11. For F11 it was less important since unpress_all was preformed for all keys.
However, we perform sync for all the keyboard modifiers and the GetKeyboardState returns "down" for shift.
In windows7 client, we sometimes received afterwards a F11 KEYDOWN event repetition, and this caused SHIFT+F11 to be called again.
Not performing hiding of the windows while changing client resolutions, solved the problem of missing events, and I don't see any difference
in how spice looks while toggling to full screen.
Using GetAsyncKeyState, returns "UP" for shift in windows 7, and helps avoid performing shift+f11 again, if there is an F11 repetition
before we receive the KEYUP event for shift.
Enable image randomized base address, hindering some types of
security attacks by making it more difficult for an attacker
to predict target addresses.
-Release currently doesn't use precompiled headers at all
-Debug is broken since common/*.c files don't include common.h
-PCH can be enabled for all but specifically-chosen c-files
SW_CANVAS_NO_CHUNKS isn't used anywhere but in this file.
SW_CANVAS_CACHE is now defined directly in the files where it's
needed so we no longer need it in the .vcproj file.
When using config.h, it must be the very first include in all source
files since it contains #define that may change the compilation process
(eg libc structure layout changes when it's used to enable large file
support on 32 bit x86 archs). This commit adds it at the beginning
of all .c and .cpp files
spice client and spice server shares code from
common/{gdi,gl,sw}_canvas.[ch]. However, while most of the code is
shared, the server code wants a canvas compiled with
SW_CANVAS_IMAGE_CACHE defined while the client code wants a canvas
compiled with SW_CANVAS_CACHE.
The initial autotools refactoring didn't take that into account,
this is now fixed by this commit. After this commit, the canvas
files from common/ are no longer compiled as part of the
libspice-common.la convenience library. Instead, there are "proxy"
canvas source files in client/ and server/ which #include the
appropriate C files after defining the relevant #define for the
binary that is being built.
To prevent misuse of the canvas c files and headers in common/,
SPICE_CANVAS_INTERNAL must be set when including the canvas headers
from common/ or when building the c files from common/ otherwise
the build will error out.
spice Makefile.am setup is a bit confusing, with source file
names being listed several times in different Makefile.am
(generally, once in EXTRA_DIST and another time in another
Makefile.am in _SOURCES). The client binaries are built
by client/x11/Makefile.am, which means recursing into client,
then into x11 to finally build spicec. This Makefile.am is
also referencing files from common/ and client/, which is
a bit unusual with autotools.
This patch attempts to simplify the build process to get
something more usual from an autotools point of view.
The source from common/ are compiled into a libtool convenience
library, which the server and the client links against which avoids
referencing source files from common/ when building the server and
the client. The client is built in client/Makefile.am and directly
builds files from x11/ windows/ and gui/ if needed (without
recursing in these subdirectories).
This makes the build simpler to understand, and also makes it
possible to list source files once, which avoids potential
make distcheck breakage when adding new files.
There is a regression in this patch with respect to
sw_canvas/gl_canvas/gdi_canvas. They should be built with
different preprocessor #defines resulting in different behaviour
of the canvas for the client and the server. However, this is not
currently the case, both the client and the server will use the same
code for now (which probably means one of them is broken). This will
be fixed in a subsequent commit.
make distcheck passes, but compilation on windows using the
autotools build system hasn't been tested, which means it's likely
to be broken. It shouldn't be too hard ot fix it though, just let
me know of any issues with this.
client/ contains several .cpp file which only #include a .c file
of the same name. This is unusual and seems to only be done to
get C++ name mangling on the symbols defined in the C file.
Now that all headers files in common/ use extern "C", these
wrappers are no longer useful.
using updated windows libraries:
http://www.spice-space.org/download/stable/wspice-x86_08032011.ziphttp://www.spice-space.org/download/stable/wspice-x64_08032011.zip
-remove IgnoreDefaultLibraryNames="MSVCRT.lib", since pixman is now compiled
using MT threading model similar to other libraries. It used to be mistakenly
compiled with MD.
-downgrade freetype lib to 2.3.11-7, which is the one used/tested with
CEGUI 0.6.2
-pthread lib patched (InterlockedCompareExchange), so x64 client will no
longer crash on SelectClipRgn, BitBlt etc.
instead of ..\..\..\spice-protocol. Relative path to another git tree is a bit
ugly, since it requires spice-protocol to be in a specific location.
SPICE_PROTOCOL_DIR should also be used in windows qxl and vdagent instead of
SPICE_COMMON_DIR, which is an old and confusing name, due to the common
directory in spice git repo.
This patch stops us from drawing the spice client watermark at the top of
the virtual machine view. We have had requests through several channels to
remove this as it has little added value, and is seen as annoying by some.
Given that we now also have a bugzilla for this I think it is time we really
remove it.
The activex browser plugin is sending unicode16 text, where as the
xpi one is sending utf8 text. After discussing this on irc we've decided
that utf8 is what we want to use. So the client (this patch), and the
activex will be changed to expect resp. send utf8 text as the title.
Spice client controller enables external control (e.g., by XPI or ActiveX) of
the client functionality.
The controller protocol enables setting parameters (host, port, sport, pwd,
secure channels, disabled channels, title, menus, hotkeys etc.), connecting
the server, showing and hiding the client etc.
The controller is based on the cross-platform named pipe.
Spice foreign menu enables external control of the client menu.
The foreignmenu protocol enables an external application to:
add a submenu, set its title, clear it, add/modify/remove an item etc.
Foreign menu is based on the cross-platform named pipe.
