The display channel was unnecessarily set to NULL when we disconnect all the clients
(on flush display commands timeout).
As a result, we recreated the display channel when a new client was connected.
The display channel was created with default red_channel.client_cbs, while its
correct client_cbs are the ones that are set by the red_dispatcher when it creates
the first display_channel.
This fix enforces a single creation of the display channel (per qxl), via the red_dispatcher.
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.
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.
Currently when the main channel disconnects while a spicevmc channel
(such as a usbredir channel) is still connected, qemu will abort with the
following message:
ring_remove: ASSERT item->next != NULL && item->prev != NULL failed
This is caused by red_client_destroy() first calling:
rcc->channel->client_cbs.disconnect(rcc);
And then calling:
red_channel_client_destroy(rcc);
For each channel. This is fine, but the spicevmc disconnect code does a
red_channel_client_destroy(rcc) itself since as usb devices are added
/ removed, the channels carrying their traffic get connected / disconnected
and they get re-used for new devices, which won't work if the old channel is
still there when the new connection comes in.
This patch fixes the double destroy when there are still spicevmc channels
connected by not doing the red_channel_client_destroy from the spicevmc
disconnect code when not just the channel, but the entire client is
disconnecting.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Also fixup the header of server/red_parse_qxl.c, which still contained
some GPL (program rather then library) text in its header.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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.
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.
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>
spice_server_migrate_connect is in 0.8.3 in the released 0.8 branch,
and so should not be changed in 0.10. This doesn't break the 0.9.1
release which didn't contain this symbol at all, only 0.9.2 release
that hopefully no one actually packaged.
This patch reuses Dispatcher in RedDispatcher. It adds two helpers
to red_worker to keep RedWorker opaque to the outside. The dispatcher is
abused in three places that use the underlying socket directly:
once sending a READY after red_init completes
once for each channel creation, replying with the RedChannel instance
for cursor and display.
FDO Bugzilla: 42463
rfc->v1:
* move callbacks to red_worker.c including registration (Yonit)
* rename dispatcher to red_dispatcher in red_worker.c and red_dispatcher.c
* add accessor red_dispatcher_get_dispatcher
* s/dispatcher_handle_recv/dispatcher_handle_recv_read/ and change sig to
just Dispatcher *dispatcher (was the SpiceCoreInterface one)
* remove SpiceCoreInterface parameter from dispatcher_init (Yonit)
* main_dispatcher needed it for channel_event so it has it in
struct MainDispatcher
* add dispatcher_get_recv_fd for red_worker
used for main_dispatcher only in this patch.
Dispatcher is meant to be used for Main<->any low frequency messages.
It's interface is meant to include the red_dispatcher usage:
fixed size messages per message type
some messages require an ack
Some methods are added to be used by RedDispatcher later:
dispatcher_handle_read - to be called directly by RedDispatcher epoll
based loop
dispatcher_set_opaque - to be set from red_worker pthread
dispatcher_init - allow NULL core as used by red_worker
Read and Write behavior:
Sender: blocking write, blocking read for ack (if any).
Reader: poll for any data, if such then blocking read for a
message_type and following message. repeat until poll returns
with no pending data to read.
FDO Bugzilla: 42463
This is part of the dispatcher update, extracting the dispatcher routine
from red_dispatcher and main_dispatcher into dispatcher.
Supporting multiple async operations will make it natural to support
async monitor commands and async guest io requests that could overlap in
time.
Use a Ring for AsyncCommands.
Free Desktop Bugzilla: 42463
Related FD: 41622
It can't actually happen right now, since switch-host migration scheme will take
place if the src/target server has protocol 1.
(cherry picked from commit 4b2bf4d88c branch 0.8)
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.
(cherry picked from commit f91d202eb3 branch 0.8)
(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
(cherry picked from commit 510a4ff7c4 branch 0.8)
Conflicts:
client/red_channel.h
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.
(cherry picked from commit fcb3b4ce52 branch 0.8)
Conflicts:
client/display_channel.cpp
We will add a qemu call to spice_server_migrate_start when migration starts.
For now, it does nothing, but we may need this notification in the future.
(cherry picked from commit b821316771 branch 0.8)
(1) not sending anything to a migrated client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new client migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END
from the previous migration was received for this client
(3) use the correct ticket
Note: we assume the same channles are linked before and ater migration. i.e.,
SPICE_MSGC_MAIN_ATTACH_CHANNELS is not sent from the clients.
If the migration has completed successfully:
(1) send MSG_MAIN_MIGRATE_END to the clients that are connected to the target
(2) send MSG_MAIN_SWITCH_HOST to all the other clients
If the migration failed, send MSG_MAIN_MIGRATE_CANCEL to clients that are
connected to the target.
(cherry picked from commit 4b82580fc3 branch 0.8;
Was modified to support multiple clients, and the separation of main_channel from reds)
Conflicts:
server/reds.c
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(to all the clients that support it)
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients,
or a timeout, in order to complete client_migrate_info monitor command
(cherry picked from commit 5560c56ef0 branch 0.8;
Was modified to support the separation of main channel from reds, and multiple clients)
Conflicts:
server/reds.c
semi-seamless migration details:
migration source side
---------------------
(1) spice_server_migrate_connect (*): tell client to link
to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN.
This should be called upon client_migrate_info cmd.
client_migrate_info is asynchronous.
(2) Complete spice_server_migrate_connect only when the client has been connected
to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout.
(3) spice_server_migrate_end: tell client migration it can switch to the target - send
SPICE_MSG_MAIN_MIGRATE_END.
(4) client cleans up all data related to the connection to the source and switches to the target.
It sends SPICE_MSGC_MAIN_MIGRATE_END.
migration target side
---------------------
(1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0)
(2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END
from the client.
* After migration starts, the target qemu is blocked and cannot accept new spice client
connections. Thus, we trigger the connection to the target upon client_migrate_info
command.
(cherry picked from commit 6e56bea67c branch 0.8)
Conflicts:
server/spice.h
The code for setting and testing channel capabilities was
unnecessarily duplicated. Now it is in red_channel.
RedsChannel was dropped from Reds; It was used only for holding
the channels common capabilities, which are now held in RedChannel.
add main_dispatcher, a message passing mechanism for sending messages to
the main thread. The main thread is the thread that implements
SpiceCoreInterface, which is assumed to be a single thread.
Similar to the async operation of red_worker, a socket pair is created
and used to pass messages. The messages are a fixed size to ease
parsing. A single message is defined to pass a channel_event.
RHBZ: 746950
FDBZ: 41858
This patch is 0.8 branch only, for the master branch there should be a
better approach to share code with red_dispatcher and ready the way for
later adding more threads.
cherry-pick from 0.8 80caf07e09
Conflicts:
server/reds.c
When using pkg-config, Requires and Requires.private field list
packages required by this package, but packages listed under
Requires.private are not taken into account when a flag list is
computed for dynamically linked executable. In the situation
where each .pc file corresponds to a library, Requires.private
shall be used exclusively to specify the dependencies between
the libraries.
