summaryrefslogtreecommitdiffstats
path: root/server/red_worker.c
Commit message (Collapse)AuthorAgeFilesLines
* Bump SPICE_INTERFACE_QXL_VERSION_MINORSøren Sandmann Pedersen2012-09-111-2/+6
| | | | | Then check that we have the right version before accessing the set_client_capabilities() function.
* Set a8 capability in the QXL device if supported by the clientSøren Sandmann Pedersen2012-09-071-0/+2
|
* Process outstanding commands in the ring after changing capability bitsSøren Sandmann Pedersen2012-09-071-0/+5
| | | | | | | | | | | 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>
* Add new set_client_capabilities() interface to QXLInstanceSøren Sandmann Pedersen2012-09-061-0/+24
| | | | | | | | | | | | | | | | | | | | | 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.
* server/red_parse_qxl: add bitmap consistency checkAlon Levy2012-09-031-15/+0
| | | | | | | | | | | 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 .
* server: replace syntax-check reported tabs with spacesAlon Levy2012-09-031-1/+1
|
* server/red_worker: seamless: fix invalid memory referenceAlon Levy2012-08-301-3/+3
| | | | | | | | | 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).
* server: freezed->froze, missing whitespace after declarationsAlon Levy2012-08-301-3/+4
|
* server/red_worker: handle_dev_update_area: fail if invalid areaAlon Levy2012-08-271-0/+6
|
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-4/+3
| | | | The relevant flags reside in RedChannelClient and RedClient
* display migration: restore destination stateYonit Halperin2012-08-271-74/+148
| | | | | | Restoring display channel from migration data. Not notifying client about changes that are artifacts of loading the vm. Remove legacy migration code.
* display migration: marshall migration dataYonit Halperin2012-08-271-6/+46
|
* display & cursor migration: send SPICE_MSG_MIGRATEYonit Halperin2012-08-271-52/+3
|
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-9/+14
| | | | | | | The relevant code is common to all channels. The patch also contains a fix to the return value for handle_migrate_data callback: s/uint64_t/int
* Add support for QXLComposite to spice serverSøren Sandmann Pedersen2012-08-241-0/+104
| | | | | | In red-parse-qxl.c add support for parsing QXLComposite into SpiceComposite. In red-worker.c add support for marshalling SpiceComposite onto the wire.
* Add support for LZ compression of A8 imagesSøren Sandmann Pedersen2012-08-241-8/+15
| | | | | | 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.
* red_worker: Fix reference counting for the current frame (drawable) of a streamYonit Halperin2012-07-251-15/+1
| | | | | | | | | | | | | | | | | 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).
* server: add monitors_config supportAlon Levy2012-07-221-1/+246
| | | | | | | | | | | | | | | | 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.
* server/red_worker: release bad drawablesAlon Levy2012-07-221-3/+2
|
* server: don't abort on guest images with missing palettesAlon Levy2012-07-221-0/+4
|
* server: factor out bitmap_fmt_is_rgbAlon Levy2012-07-221-8/+7
|
* server/red_worker: fix wrong spice_error in commit 706232a8Alon Levy2012-07-111-16/+16
|
* server/red_worker: elevate some spice_debugs to spice_infoAlon Levy2012-07-051-52/+52
| | | | | | 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.
* server/red_worker: cleanup lines starting with 5 spacesAlon Levy2012-07-051-13/+13
|
* server/red_worker: death to spice_printerr, too verbose by farAlon Levy2012-07-051-91/+91
| | | | | Replaced mostly with spice_debug, but spice_warning & spice_error as well where appropriate.
* server/red_worker: fix red_wait_pipe_item_sentYonit Halperin2012-05-241-7/+5
| | | | | | | | | | | | | | | 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.
* server/red_channel: remove red_channel_client_item_being_sentYonit Halperin2012-05-241-3/+1
| | | | | | 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.
* server: handle red_channel_client_create returning NULLYonit Halperin2012-05-211-0/+3
|
* server/video: do not allow non-streamable drawables be stream candidatesYonit Halperin2012-05-211-0/+4
| | | | | | | | | 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.
* server: move self_bitmap_image to RedDrawableAlon Levy2012-05-151-16/+9
| | | | | | | 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.
* server/red_worker/put_red_drawable: s/drawable/red_drawable/Alon Levy2012-05-151-6/+6
|
* server/red_worker/red_handle_self_bitmap: add red_drawable local, one extra ↵Alon Levy2012-05-151-7/+7
| | | | whitespace line removed
* server/red_worker: rename SpiceImage *self_bitmap to self_bitmap_imageAlon Levy2012-05-151-13/+13
|
* Revert "server/red_worker: fix possible leak of self_bitmap"Alon Levy2012-05-151-7/+5
| | | | | | | This reverts commit 35dbf3ccc4b852f9dbb29eb8a53c94f26d2e3a6e. accidentally pushed v1 of patches, reverting in preperation of pushing v2.
* server/red_worker: fix possible leak of self_bitmapAlon Levy2012-05-141-5/+7
| | | | | | | | | | | | | | | 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.
* server/red_worker/red_process_commands: rename drawable to red_drawable ↵Alon Levy2012-05-141-4/+4
| | | | (later add a local drawable)
* server/red_worker: red_process_drawable: have single point of exitAlon Levy2012-05-141-8/+5
|
* server/red_worker: don't release self_bitmap unless refcount is 0Yonit Halperin2012-05-141-4/+3
| | | | RHBZ: 808936
* server/red_worker/video: don't override the clip in areas that belong only ↵Yonit Halperin2012-05-031-30/+12
| | | | to sized frames
* server/red_worker.c/video: add support for frames of different sizesYonit Halperin2012-05-031-51/+158
| | | | | | | | | | | | 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.
* Update the spice-common submoduleYonit Halperin2012-05-031-2/+2
| | | | | | | | | 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.
* server/red_worker/video: don't detach a drawable from a stream due to it ↵Yonit Halperin2012-05-031-8/+8
| | | | | | | | | | | being rendered. 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.
* server/red_worker/video: upgrade stream by a screenshot instead of the last ↵Yonit Halperin2012-05-031-21/+71
| | | | | | | | frame, if needed 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.
* server/red_worker/video: maintain visible region and clip region for streamsYonit Halperin2012-05-031-12/+27
| | | | | | | | | | | | | | | | | | | | | 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.
* server/red_worker: add get_stream_idYonit Halperin2012-05-031-11/+16
|
* Force 64 bit multiplication on 32 bit systems; fixes a bug where the server ↵Jeremy White2012-04-271-1/+1
| | | | times out the display channel freakily fast.
* Add some more 'noreturn' annotationsDaniel P. Berrange2012-04-251-2/+4
| | | | | | | | 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>
* Fix typo in is_equal_brushDaniel P. Berrange2012-04-251-1/+1
| | | | | | | 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>
* Remove 2 *MB* stack frame in red_worker_mainDaniel P. Berrange2012-04-251-25/+25
| | | | | | | | | | 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>
* Mark some variables as volatileDaniel P. Berrange2012-04-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit (git 2.34.1) at 2024-05-27 11:03:50 +0000