When a new client connects, there may be commands in the ring that it
can't understand, so we need to process these before forwarding new
commands to the client. By doing this after changing the capability
bits we ensure that the new client will never see a command that it
doesn't understand (under the assumption that the guest will read and
obey the capability bits).
Acked-by: Alon Levy <alonl@redhat.com>
A new interface
set_client_capabilities (QXLInstance *qin,
uint8_t client_present,
uint8_t caps[58]);
is added to QXLInstance, and spice server is changed to call it
whenever a client connects or disconnects. The QXL device in response
is expected to update the client capability bits in the ROM of the
device and raise the QXL_INTERRUPT_CLIENT interrupt.
There is a potential race condition in the case where a client
disconnects and a new client with fewer capabilities connects. There
may be commands in the ring that the new client can't handle. This
case is handled by first changing the capability bits, then processing
all commands in the ring, and then start forwarding commands to the
new client. As long as the guest obeys the capability bits, the new
client will never see anything it doesn't understand.
Just checks stride vs width times bpp.
This fixes a potential abort on guest generated bad images in
glz_encoder.
Other files touched to move some consts to red_common, they are
static so no problem to be defined in both red_worker.c and
red_parse_qxl.c .
replace add_ref with add for stack allocated SpiceMigrateDataDisplay.
This fixes wrong MIGRATE_DATA message in display channel (symptom is
glz_encoder_max being way too big, and malloc failure at target) seen on
F18 with gcc-4.7.1-5.fc18.x86_64 and glibc-2.16-8.fc18.x86_64 (didn't
appear on RHEL 6).
Graduality is irrelevant for A8 images, so instead of using RGB-ness
as a short-cut, add a new macro BITMAP_FMT_HAS_GRADUALITY() that
returns true for the existing RGB images, but false for A8.
After marshalling MSG_STREAM_CREATE, there is no need to ref and
unref stream->current before and after completing the sending of the
message (correspondingly). The referencing is unnecessary because all
the data that is required from the drawable (the clipping), is copied
during marshalling, and no field in the drawable is referenced (see
spice_marshall_msg_display_stream_create).
Moreover, the referencing was bugous:
While display_channel_hold_pipe_item and
display_channel_client_release_item_after_push referenced and
dereferenced, correspondingly, stream->current, stream->current might
have changed in between these calls, and then we ended up with one drawable
leaking, and one drawable released before its time has come (which
of course led to critical errors).
a SpiceMsgDisplayMonitorsConfig is sent on two occasions:
* as a result of a spice_qxl_monitors_config_async
* whenever a client connects and there is a previously set monitors
config
Sending the new message is protected by a new cap,
SPICE_DISPLAY_CAP_MONITORS_CONFIG
More elaborately:
spice_qxl_monitors_config_async receives a QXLPHYSICAL address of a
QXLMonitorsConfig struct and reads it, caching it in the RedWorker, and
sending it to all clients. Whenever a new client connects it receives
a SpiceMsgDisplayMonitorsConfig message as well.
Specifically all those that the previous patch converted to spice_debug.
spice_debug contains very verbose stuff like update_area that drowns out
those relatively rare (client connect / disconnect generated) messages.
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.
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.
Differentiate between the clipping of the video stream, and the region
that currently displays fragments of the video stream (henceforth,
vis_region). The latter equals or contains the former one. For example,
let c1 be the clip area at time t1, and c2 be the clip area at time t2,
where t1 < t2. If c1 contains c2, and at least part of c1/c2, hasn't been
covered by a non-video images, vis_region will contain c2, and also the part
of c1/c2 that still displays fragments of the video.
When we consider if a stream should be "upgraded" (1), due to its area
being used by a rendering operation, or due to stopping the video, we
should take into account the vis_region, and not the clip region (next
patch: not upgrade by the last frame, but rather by vis_region).
This fix will be more necessary when sized frames are introduced (see the
following patches). Then, the vis_region might be larger
than the last frame, and contain it, more frequently than before.
(1) "upgrading a stream" stands for sending its last frame losslessly. Or more
precisely, lossless resending of all the currently displayed lossy areas, that were
sent as part of the stream.
Methods which longjump, unconditionally raise an
exception, or call _exit() cannot return control
to the caller so should be annotated with 'noreturn'
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The 3 part of the conditional in the is_equal_brush method
compared the b1->u.color field to itself, instead of b2->u.color
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The red_worker_main method allocates a RedWorker struct instance
on the stack. This struct is a full 2 MB in size which is not
at all resonable to allocate on the stack.
* server/red_worker.c: Move RedWorker struct to the heap
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When using setjmp/longjmp the state of local variables can be
undefined in certain scenarios:
[quote man(longjmp)]
The values of automatic variables are unspecified after a
call to longjmp() if they meet all the following criteria:
· they are local to the function that made the correspond‐
ing setjmp(3) call;
· their values are changed between the calls to setjmp(3)
and longjmp(); and
· they are not declared as volatile.
[/quote]
* server/red_worker.c: Mark some vars as volatile
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
