This patch and the following one do not introduce tokening to the
spicevmc channel. But this can be done easily later, by setting the appropriate
variables in SpiceCharDeviceState (after adding
the appropriate protocol messages, and implementing this in the client
side).
This code is never called, it was relevant for seamless migration.
Most of the data that needs to be migrated was moved to
SpiceCharDeviceState. When we implement seamless migration,
we will have routines in char_device.c for migrating the relevant data.
- Allow sending tokens to a specific client.
- Do not ignore tokens that are sent from the client to the server.
The tokens support for multiple clients and for server side tokens
is still broken in reds. It will be fixed in following patches, when
the server-side agent code will use the SpiceCharDeviceState api.
Notice that ignoring the server-side tokens didn't introduce a problem
since both the client and the server set it to ~0.
SpiceCharDeviceState manages the (1) write-to-device queue
(2) wakeup and reading from the device (3) client tokens (4)
sending messages from the device to the client/s, considering the
available tokens.
SpiceCharDeviceState can be also stopped and started. When the device
is stopped, no reading or writing is done from/to the device. Messages
addressed from the client to the device are being queued.
Later, an api for stop/start will be added to spice.h and it should
be called from qemu.
This patch does not yet remove the wakeup callback from
SpiceCharDeviceState, but once all the char devices (agent/spicevmc/smartcard)
code will switch to the new implementation, SpiceCharDeviceState
will be moved to the c file and its reference to the wakeup callback will be removed.
Current bumped and age bumped for new intefaces only (no backward
incompatible changes).
New libtool version is 2.0.1, using --version-info instead of
--version-name. Doing the version change and --version-name to
--version-info change here to avoid changing the libtool version twice.
Added interfaces:
spice_server_set_name
spice_server_set_uuid
spice_server_set_listen_socket_fd
spice_server_is_server_mouse
New library name in linux:
libspice-server.so.1.1.0
Old:
libspice-server.so.1.0.2
The red_channel_client_event call to red_channel_client_receive might result
in a disconnected channel client. The following call to
red_channel_client_push may call to red_peer_handle_outgoing with a
disconnected socket.
Added ref count for RedChannel and RedChannelClient.
red_channel.c/red_peer_handle_incoming call to
handler->cb->handle_message might lead to the release of the channel
client, and the following call to handler->cb->release_msg_buf will be
a violation.
This bug can be produced by causing main_channel_handle_parsed
call red_client_destory, e.g., by some violation in
reds_on_main_agent_data that will result in a call to reds_disconnect.
Resolves: rhbz#824384
red_wait_pipe_item_sent mistakingly returned without waiting for sending the given pipe item
when the channel wasn't blocked. As a result, we failed when we had to
destroy a surface (e.g., QXL_IO_DESTROY_ALL_SURFACES) and to release all
the drawables that are depended on it (by removing them or waiting they will be sent).
In addition, red_wait_pipe_item_sent increased and decreased the reference to the pipe item
using channel_cbs->hold_item, and channel_cbs->release_item. However,
these calls can be called only by red_channel, otherwise
display_channel_client_release_item_before_push is called twice and
leads to a double call to ring_remove(&dpi->base).
Instead ref/put_drawable_pipe_item should be called.
The above routine was risky, since red_channel_client_init_send_data
can also be called with item==NULL. Thus, not all pipe items can be tracked.
The one call that was made for this routine was not necessary.
Resolves: rhbz#820669
Fix a segfault caused by a call to __red_is_next_stream_frame made by
red_stream_maintenance, with a drawable that is not a DRAW_COPY one.
The segfault is a reault of __red_is_next_stream_frame accessing
red_drawable->u.copy.src_bitmap for a non DRAW_COPY drawable.
Before, we tested only higher frames, while wider frames would have
triggered a bug in mjpeg_encoder, when spice is linked with libjpeg and
not libjpeg-turbo.
Simplify keeping count of self_bitmap_image by putting it in
RedDrawable. It is allocated on reading from the command pipe and
deallocated when the last reference to the RedDrawable is dropped,
instead of keeping track of it in GlzDrawable and Drawable.
After the previous patch moving self_bitmap freeing inside red_drawable
ref count, we have a possible self_bitmap leak:
red_process_commands
red_get_drawable | red_drawable #1, red_drawable->self_bitmap == 1
red_process_drawable | rd #2, d #1, d->self_bitmap != NULL
release_drawable | rd #1, d# = 0, try to release self_bitmap, but
blocked by rd #1
put_red_drawable | rd #0
This patch moves the call to release_drawable after the call to
put_red_drawable, thereby fixing the above situation.
rhbz #813826
When playing a youtube video on Windows guest, the driver sometimes(**) sends
images which contain the video frames, but also other parts of the
screen (e.g., the youtube process bar). In order to prevent glitches, we send these
images as part of the stream, using SPICE_MSG_DISPLAY_STREAM_DATA_SIZED.
(**) It happens regularly with the you tube html5 player. With flash,
it occurs when moving the cursor in the player area.
spice-common changes: STREAM_DATA_SIZED message was added in order to support
video streams with frames that their size is different from the initial size
that the stream was created with.
This patch also includes server and client adjustments to the new
SpiceMsgDisplayStreamData.
The previous patch took care that streams will be upgraded by a surface
screenshot and not the last frame, if necessary. Thus, there is no
more a reason for detaching drawables from streams when they are
rendered. Moreover, detaching such drawables can cause glitches, in
case they are still in the pipe, and red_update_area is called
frequently and leads to stream frames rendering.
Upgrading a stream: When the stream's visible region is bigger than the one of the last
frame, we will send an updated screenshot of the visible region, instead
of sending the last frame losslessly.
