The endless recursion happens due to Application::prepare_monitors calling RedScreen::resize
calling Application::rearrange_monitors calling Application::prepare_monitors
I changed RedScreen::resize not to call rearrange_monitors. Instead,
the monitor should be configured correctly from Application, before
calling resize.
In addition, I made some cleanups to allow reusing rearrange_monitors code.
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.
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
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.
The OpenGL renderer isn't really useful right now, its not quite up
to date, its not really faster than software and it only supports a limited
subset of drivers. So, lets disable it for now.
Long term opengl rendering of the 2d part of spice is important if we want
to combine 2d and 3d rendering (say if spice adds opengl support in the
protocol). But until then this is isn't useful for normal use.
In order to be able to support 16bit canvases on 32bit screens and 32bit
canvases on 16bit screens we need to handle format conversion when drawing
RedPixmaps.
The way this works now for X11 is that we only have one PIXELS_SOURCE_TYPE
for pixmaps, which always has a pixman_image_t for the data, but additionally
it has an XImage (shared mem or not) if the screen the pixmap was created
for (i.e. an explicit one or the default screen) has the same format as
the pixmap.
When we draw a pixmap on a drawable we have two variants. If the pixmap
has a XImage and it matches the format of the target drawable then we
just X(Shm)PutImage it to the drawable. If the formats differ, then we
create a temporary XImage and convert into that before drawing it to
the screen.
Right now this is a bit inefficient, because we always allocate a new
temporary image when converting. We want to add some caching here, but
at least this lets things work again.
We now support 16bit format pixmaps as well as the old ones. Including
both 555 and 565 modes.
We drop the palette argument for pixmap construction as it was only
used for black/white anyway.
Canvas creation is simplified so that there is no separate set_mode
state. Canvases are already created in the right mode and never change.
pixman_region32_t is an efficient well tested region implementation (its
the one used in X) that we already depend on via pixman and use in
some places. No need to have a custom region implementation.
Screen now have to modes locked and unlocked.
In unlocked mode, the application can change screen size and so
reduce resolution changing. The application can also choose to
change window size while not in full screen mode.
In locked mode the application must ewtain locker screen size
setting.
Additional changes that were required for the feature:
1) focusing on the pointed window in full screen mode
2) In X11 - handling events that occur during keyboard ungrabbing
3) In X11 - handling Leave/Enter Notify events that occur during keyboard grabbing/ungrabbing
4) In X11 - fix for focus events that are handled in the wrong order (happens when
focus events occur during grabbing the keyboard)
5) In X11 - ignoring key release events during key holding
6) In Windows - synchronizing keyboard release events that occured during a modal loop
The process loop is responsible for: 1) waiting for events 2) timers 3) events queue for
actions that should be performed in the context of the thread and are pushed from other threads.
The benefits:
1) remove duplicity: till now, there was one implementaion of events loop for the channels and
another one for the main thread.
2) timers can be executed on each thread and not only on the main thread.
3) events can be pushed to each thread and not only to the main thread.
In this commit, only the main thread was modified to use the new process loop.
