summaryrefslogtreecommitdiffstats
path: root/server/red_worker.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Mark functions which never return controlDaniel P. Berrange2012-04-251-3/+2
| | | | | | | | * client/red_channel.cpp: AbortTrigger::on_event can't return given its current impl * server/red_worker.c: red_worker_main can't return Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Fix multiple printf format problemsDaniel P. Berrange2012-04-251-6/+6
| | | | | | | | | | | | | | | | All printf var-args style methods should be annotation with their format. All format strings must be const strings. * client/application.cpp, client/cmd_line_parser.cpp, client/hot_keys.cpp: Avoid non-const format * client/client_net_socket.cpp: Fix broken format specifier * client/red_peer.cpp: Fix missing format specifier * client/platform.h: Add SPICE_GNUC_PRINTF annotation to term_printf * client/utils.h: Add SPICE_GNUC_PRINTF annotation to string_printf * server/glz_encoder_config.h, server/red_worker.c: Add SPICE_GNUC_PRINTF annotation to warning callbacks Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Fix const-ness violationsDaniel P. Berrange2012-04-251-1/+1
| | | | | | | * server/red_worker.c: Add missing const for return type * server/reds.c: Static strings must be declared const Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* server: allow failure in getvirtAlon Levy2012-04-051-14/+33
| | | | | | | This patch changed getvirt to continue working even if spice_critical doesn't abort (i.e. SPICE_ABORT_LEVEL != -1). This is in preparation to make getvirt not abort at all. The reason is that getvirt is run on guest provided memory, so a bad driver can crash the vm.
* Use the spice-common logging functionsMarc-André Lureau2012-03-251-298/+304
| | | | | It will abort by default for critical level messages. That behaviour can be tuned at runtime.
* Use the spice-common submoduleMarc-André Lureau2012-03-251-12/+14
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* server/red_worker: fix for case where ASSERT is compiled outAlon Levy2012-03-211-2/+1
|
* server/red_worker: don't typedef SpiceWatch twiceAlon Levy2012-03-201-2/+2
| | | | First defined in spice.h, fixes build failure with gcc 4.4.6
* red_worker: Check for NULL watchesHans de Goede2012-03-131-2/+13
| | | | | | | | If we run out of watches slots, we return NULL from watch_add, which means that the other watch_foo functions may get called with a NULL parameter, protect them against this. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_worker: Rework poll code to use the watch interfaceHans de Goede2012-03-121-91/+79
| | | | | | | | | | | | | | | | | | | | | | | | | Commit 143a1df24e83e9c1e173c16aeb76d61ffdce9598 changed red_worker_main from epoll to poll. But epoll has edge triggered semantics (when requested and we requested them), where as poll is always level triggered. And red_worker was relying on the edge triggered semantics, as it was always polling for POLLOUT, which, when edge triggered, would only cause poll to register an event after we had blocked on a write. But after the switch to regular poll, with its level triggered semantics, the POLLOUT condition would almost always be true, causing red_worker_main to not block on the poll and burn CPU as fast as it can as soon as a client was connected. Luckily we already have a mechanism to switch from polling for read only to polling for read+write and back again in the form of watches. So this patch changes the red_worker dummy watch implementation into a proper watch implementation, and drops the entire EventListener concept since that then is no longer needed. This fixes spice-server using 400% CPU on my quad core machine as soon as a client was connected to a multi head vm, and as an added bonus is a nice cleanup IMHO. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_worker: Remove ref counting from the EventListener structHans de Goede2012-03-101-34/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The red_worker EventListener struct is either embedded in one of: 1) DisplayChannelClient 2) CursorChannelClient 3) RedWorker And as such gets destroyed when these get destroyed, in case 1 & 2 through a call to red_channel_client_destroy(). So free-ing it when the ref-count becomes 0 is wrong, for cases: 1) and 2) this will lead to a double free; 3) this will lead to passing memory to free which was not returned by malloc. This is not causing any issues as the ref-count never gets decremented, other then in red_worker_main where it gets incremented before it gets decremented, so it never becomes 0. So we might just as well completely remove it. Notes: 1) This is mainly a preparation patch for fixing issues introduced by the move from epoll to poll 2) Since removing the ref-counting removes the one code path where listeners would get set to NULL, this patch moves the setting of NULL to pre_disconnect, where it should have been done in the first place since red_client_destroy calls red_channel_client_disconnect (through the dispatcher) followed by red_channel_client_destroy, so after pre_disconnect the listener may be gone. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Ensure all members of ChannelCbs and ClientCbs are either assigned or NULLHans de Goede2012-03-101-1/+1
| | | | | | | | | | | | | | | While git-bisecting another issue I ended up hitting and not recognizing the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb. While fixing this (again) I noticed that (even after the fix) not all users of ChannelCbs first zero it. So this patch ensures that all users of ChannelCbs first zero it, and does the same for ClientCbs while at it. Since before this patch there were multiple zero-ing styles, some using memset and other using a zero initializer this patch also unifies all the zero-ing to use a NULL initializer for the first element. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/red_worker: fix use after free for listenersAlon Levy2012-03-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a core dumped observed once by repeated migration. So far 100 migrations and no recurrence. Core was generated by `/home/alon/spice/upstream/bin/qemu-system-x86_64 --enable-kvm -qmp unix:/tmp/mi'. Program terminated with signal 11, Segmentation fault. 11197 if (evt_listener && evt_listener->refs > 1) { Missing separate debuginfos, use: debuginfo-install bluez-libs-4.98-3.fc17.x86_64 brlapi-0.5.6-4.fc17.x86_64 bzip2-libs-1.0.6-4.fc17.x86_64 cryptopp-5.6.1-6.fc17.x86_64 keyutils-libs-1.5.5-2.fc17.x86_64 libssh2-1.4.0-1.fc17.x86_64 nss-softokn-freebl-3.13.1-20.fc17.x86_64 xen-libs-4.1.2-11.fc17.x86_64 xz-libs-5.1.1-2alpha.fc17.x86_64 (gdb) bt (gdb) l 11192 for (i = 0; i < MAX_EVENT_SOURCES; i++) { 11193 struct pollfd *pfd = worker.poll_fds + i; 11194 if (pfd->revents) { 11195 EventListener *evt_listener = worker.listeners[i]; 11196 11197 if (evt_listener && evt_listener->refs > 1) { 11198 evt_listener->action(evt_listener, pfd); 11199 if (--evt_listener->refs) { 11200 continue; 11201 } (gdb) p evt_listener $1 = (EventListener *) 0x7f15a9a5d1e0 (gdb) p *evt_listener Cannot access memory at address 0x7f15a9a5d1e0 (gdb) p i $2 = 2 (gdb) p worker.listeners $3 = {0x7f15bc832520, 0x7f15a406e1a0, 0x7f15a9a5d1e0, 0x0 <repeats 17 times>}
generated by cgit (git 2.34.1) at 2024-09-28 16:26:50 +0000