[Spice-commits] server/red_worker.c

[Yonit Halperin]

 server/red_worker.c |    5 -----
 1 file changed, 5 deletions(-)

New commits:
commit 5c91735b2c81a47cf88c84256f4d36a888923549
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Wed Dec 5 12:34:28 2012 -0500

    red_worker: revert 8855438a
    
    red_proccess_commands calls were added after calling
    guest_set_client_capabilities in order to cleanup the command ring from
    old commands that the client might not be able to handle.
    However, calling red_process_commands at this stage does send messages
    to the client.
    In addition, since setting the client capabilities at the guest is not
    synchronized, emptying the command ring is not enough in order to make
    sure the following commands will be supported by the client.
    The call to red_proccess_commands before initializing the display
    streams (the call to red_display_start_streams), caused inconsistencies
    related to video streaming upon reconnecting (rhbz#883564).
    
    I'm reverting this patch till another solution for the capabilities
    mismatch is introduced.
    
    Resolves: rhbz#883564

diff --git a/server/red_worker.c b/server/red_worker.c
index 8f7f45a..530562b 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -9515,11 +9515,6 @@ static void on_new_display_channel_client(DisplayChannelClient *dcc)
     }
     red_channel_client_ack_zero_messages_window(&dcc->common.base);
     if (worker->surfaces[0].context.canvas) {
-        int ring_is_empty;
-
-        while (red_process_commands(worker, MAX_PIPE_SIZE, &ring_is_empty)) {
-        }
-        
         red_current_flush(worker, 0);
         push_new_primary_surface(dcc);
         red_push_surface_image(dcc, 0);