The default stays the same -- false.
A race could prevent setting ForeignMenu::_active correctly.
That happened when Application::on_app_activated was called before
_foriegn_menu was created. When foriegn_menu was created its
_active defaults to false, and that has not changed, until focus
was taken out and back in spice-client window.
This caused usbrdr to sometimes not auto-share devices, unless
the user switched focus to a different application and back to
spicec.
The fix updates ForiegnMenu::_active upon creation.
(cherry picked from commit fdcef17364)
RedWindow::set_menu() can fail (on Windows when in fullscreen mode).
For Windows spice-client, when in fullscreen mode, the system-menu
is NULL.
Returns 0 upon success, non-0 (currently only -1) upon failure.
(cherry picked from commit 24d5852611)
(seperator vs separator --> a small typo that got fixed)
Hello,
The second patch check to see if Windows is sending a fake VK_CONTROL
message when the user pressed Alt-Gr when using a non-US keyboard layout
(German, Czech, etc...).
If the function is_fake_ctrl return true and key event is translated to
a REDKEY_INVALID and the event is discarded.
Gal.
(cherry picked from commit 9ffa2e9990)
Hello,
I first updated the translate_key function. It now requires the windows
message as parameter (will be used later). It also use the raw wparam
and lparam parameters in order to remove the code duplication when
calling the function.
Gal.
(cherry picked from commit 33be8633f5)
RHEL-6 Bugzilla: 695323
cherry-picked from qspice commit
003667ac99beeec9b330a07bc3569c59a96d4588
which fixes RHEL-5 541566
with merge of the one line qspice fix to SPICE_REQUIRES:
9f3fe4755f11044a45c4b21148466a997fcbf735
spice: fixed reference to xinerama pkg config file
(Xinerama.pc=>xinerama.pc)
Author: Yonit Halperin <yhalperi@redhat.com>
(cherry picked from master, commit a30d96faa49bca73f9c6000c4123a8ffb996ee1b)
Conflicts:
client/Makefile.am
Implement on_disconnect_mig_src and on_connect_mig_target in order to avoid
unnecessary cleanups done in on_(disconnet|connect).
In addition, do not request guest display settings changes after migration.
(1) disconnect all channels from the migration src
(2) after all channels are disconnected, clean global resources
(3) send SPICE_MSGC_MAIN_MIGRATE_END to migration target
(4) wait for SPICE_MSG_MAIN_INIT
(4) switch all channels to migration target
use std::map instead of a specific template (CHash).
There is no need for special template. Moreover, using
std::map will allow easy iteration over the surfaces.
In a Xinerama setup, when X starts up and creates one of the
secondary screens, first a non-primary surface is created on the
secondary screen, and then the primary surface for this screen is
created.
This causes a crash when the guest uses Xinerama and the client
is attached to the VM before X starts (ie while the guest is
booting).
This happens because DisplayChannel::create_canvas (which is called
when creating a non-primary surface) assumes a screen has already been
set for the DisplayChannel while this only happens upon primary surface
creation. However, it uses the screen for non important stuff, so we
can test if screen() is non NULL before using it. This is what is done
in other parts of this file.
Fixes rhbz #732423
After hours of investigation, I am a bit clueless.. It seems XRR is sending
us spurious ScreenChangeNotify in a loop. So we keep calling
init_monitors(), which creates new platform_win etc.. Although none of the
clients seems to be resetting the screen (checked all XRRSet..). The fact
that we create many platform_win looks like a bug to me, and indeed, it
seems to help if we reuse the same platform_win over the various
init_monitors() calls.
Fixes rhbz #692833
Even if VDAgentDisplayConfig::depth will be unused if the
VD_AGENT_DISPLAY_CONFIG_FLAG_SET_COLOR_DEPTH isn't set, it's
better to initialize it anyway to avoid warnings from valgrind.
Changelog from Arnon Gilboa, patch from me:
Commit eb6f554094 caused the following regression:
When client runs without the auto-conf or disable-effects options
(either from CLI or controller), which is the case when using Spice
from Admin Portal, the client will unecessarily wait for 30sec before
connecting to a Windows guest with an agent running (this won't happen
with linux guests or without an agent running).
The mentioned patch assumed that on_agent_reply() of
VD_AGENT_DISPLAY_CONFIG will call send_main_attach_channels() and
connect. However, when auto-conf or disable-effects are not used,
on_agent_reply() will ignore the reply and not call
send_main_attach_channels(). Therefore, send_main_attach_channels()
will only be called on agent timeout.
The solution is to activate agent timer only if auto-conf or
disable-effects. Otherwise, simply call send_main_attach_channels().
Fixes rhbz #726441
When the client connects to a spice VM, if an agent is detected,
there will be a few messages exchanged to exchange capabilities,
display resolutions, ... This exchange has a timeout in case
something goes wrong. However, when it fires, the client dies.
This commit changes this and lets the client connects to the
guest when the timeout happens.
rhbz #673973
492f7a9b fixed unwanted timeouts during initial client startup,
but it also caused a bad regression when connecting to
RHEL6+agent guests: the SPICE_MSGS_MAIN_ATTACH_CHANNELS message
was sent multiple times, once in RedClient::handle_init, then
once again in RedClient::on_agent_announce_capabilities (which
can even be triggered multiple times). Sending this message multiple
times is a big NO and causes the server to close the client connection,
and the client to die. Add a _msg_attach_message_sent boolean to
make sure we only send this message once.
rhbz #712938
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.
Both connect_secure() and connect_unsecure() call connect_to_peer().
Prior to this commit spicec.log reported all connections as unsecure,
as connect_secure() called connect_unsecure() to make the connection.
This fixes RH bug #653545
If you try to connect to a linux guest with WAN options, SPICE window opens up
and is blank - it then fails with vdagent timeout message. It should give a
warning that this is only applicable for windows guest and still connect to
guest.
It all starts in RedClient::handle_init
This function checks whether we have an agent or not, because if we have an
agent, there will be some kind of handshake to check both sides capabilities
before all the spice channels are created.
When there is no agent running, the startup process goes on with
SPICE_MSGC_MAIN_ATTACH_CHANNELS
When there is a windows agent running, VD_AGENT_ANNOUNCE_CAPABILITIES and
VD_AGENT_DISPLAY_CONFIG messages are sent to the agent, and when processing the
agent answer to the VD_AGENT_DISPLAY_CONFIG message,
SPICE_MSGC_MAIN_ATTACH_CHANNELS will be sent and the startup process will go
on.
However, when there is no agent running but --color-depth was used, handle_init
won't send the SPICE_MSGC_MAIN_ATTACH_CHANNELS message but will wait for the
agent handshake to proceed to its end, which won't happen, so it will timeout
waiting for agent answers.
Similarly, the linux agent handles VD_AGENT_ANNOUNCE_CAPABILITIES messages, but
it doesn't handle VD_AGENT_DISPLAY_CONFIG messages, so we'll never reach the
point where a SPICE_MSGC_MAIN_ATTACH_CHANNELS will be sent.
This commit fixes this in 2 places:
- unconditionnally send SPICE_MSGC_ATTACH_CHANNELS when no agent is running in
handle_init
- send SPICE_MSGC_MAIN_ATTACH_CHANNELS in
RedClient::on_agent_announce_capabilities if the agent doesn't have the
VD_AGENT_CAP_DISPLAY_CONFIG capability
This fixes RH bug #712938
The WAN options (--color-depth and --disable-effects) need
support from the guest agent to be working. Currently they are
only supported on Windows. While I don't want to explicitly
mention Windows in --help output, we can hint that it won't
work with all guests in --help. This fixes RH bug #712941
There is a double free in client/x11/platform.cpp.
In get_selection(), in the exit: case with ret_val == -1 and data != NULL,
*data_ret (which is returned to the caller) has already been
assigned "data", so it will be pointing to freed memory when "data" is
XFree'd'. Then in handle_selection_notify, get_selection_free is called on
this pointer, which causes a double free.
When the length of the read data = 0, set the returned value to NULL,
this way subsequent free attempts will be a noop.
Fixes RH bug #710461
Enable image randomized base address, hindering some types of
security attacks by making it more difficult for an attacker
to predict target addresses.
Commit 774e5bd36f changed
- dest->source.pixmap.x_image->data +
+ (uint8_t *)pixman_image_get_stride(dest->source.pixmap.pixman_image) +
The correct accessor to use is pixman_image_get_data. Thanks to gcc
4.6 for warning about a "different size" int to pointer conversion.
The server Makefile.am rules for marshallers generation are
prefixed with AM_V_SILENT to integrate nicely with automake silent
rules. The same AM_V_SILENT prefix isn't used in client/Makefile.am
resulting in verbose output even when automake silent mode is
enabled. This commit removes this verbosity.
When OpenGL is enabled, build fails in DisplayChannel::create_surface
because Canvas *canvas is declared twice. Remove the first
declaration to fix compilation.
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.
Having a loglevel variable is much more useful if we can actually change
its value without a recompile. Use a SPICEC_LOG_LEVEL environment variable so
we can do this from the spice xpi / activex too (by setting the environment
variable before starting the browser).
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.
Video streams from Linux guests are oriented top-down, where gdi_canvas_put_image always
received display context for down-top oriented bitmap. I fixed create_bitmap
to consider the stream orientation.
