[Spice-commits] Changes to 'mc.v8'

Alon Levy alon at kemper.freedesktop.org
Sun Aug 14 05:56:46 PDT 2011


New branch 'mc.v8' available with the following commits:
commit 87a80cbfee617b76e821f37febdcbc16e1ca60dc
Author: Alon Levy <alevy at redhat.com>
Date:   Fri Aug 12 21:50:42 2011 +0300

    server/main_channel: reduce verbose agent data command
    
    by using the new SPICE_DEBUG_LEVEL.

commit 7679bc6827b0d4fc41f2fdfdeb74795dca597596
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Thu Aug 4 16:39:09 2011 +0300

    drawables count for debug

commit 71e8013377fc286cbc2103d62e0cfcf3d6f61f67
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Wed Aug 3 19:02:45 2011 +0300

    server/red_channel.c: cleanups

commit 7a6315b7608b3e4516b917a70d0e276aaef9e0fe
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Wed Aug 3 18:36:04 2011 +0300

    server: registering RedChannel in reds, instead of Channel
    
    Merging the functionality of reds::channel, into RedChannel.
    In addition, cleanup and fix disconnection code: before this patch,
    red_dispatcher_disconnect_display_client
    could have been called from the red_worker thread
    (and it must be called only from the io thread).
    
    RedChannel holds only connected channel clients. RedClient holds all the
    channel clients that were created till it is destroyed
    (and then it destroys them as well).
    
    Note: snd_channel still doesn't use red_channel, however it
    creates dummy channel and channel clients, in order to register itself
    in reds.
    
    server/red_channel.c: a channel is connected if it holds at least one channel client
    
    Previously I changed RedChannel to hold only connected channel clients and
    RedClient, to hold all the channel clients as long as it is not destroyed.

commit b1f35d339a4c889dbacefa3fc49ec12cb64e3850
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Wed Aug 3 16:04:20 2011 +0300

    server/red_channel.c inroducing client_cbs
    
    client_cbs are supposed to be called from client context (reds). This patch will be used
    in future patches for relacing reds::Channel with RedChannel in order to eliminate redundancy.

commit 9ebc044a97de1254a61d06577ba53a0fc5802d25
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Wed Aug 3 15:43:02 2011 +0300

    server/red_channel.c: pack all channel callbacks to ChannelCbs

commit 3c12c6501d2ef287469191b3311936559169539a
Author: Alon Levy <alevy at redhat.com>
Date:   Thu Apr 21 22:21:36 2011 +0300

    server/red_worker: add ref counting to RedDrawable
    
    introduces ref_red_drawable and put_red_drawable (rename from free_red_drawable)
    
    RedDrawable is already references by Drawable and RedGlzDrawable, with
    a hack to NULL the drawable field in RedGlzDrawable to indicate RedGlzDrawable
    is the last reference holder. Using an explicit reference count instead.

commit 8fa0ed33e28be4d0934f01a8cc876eee66341d4f
Author: Alon Levy <alevy at redhat.com>
Date:   Wed Jun 15 14:48:46 2011 +0200

    server/red_worker: add stream_count (for debug purposes)

commit b43a8749c1ad23a19e82c6092c8df23e1a38c8b4
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Jun 5 11:49:48 2011 +0300

    server/red_worker: validate_surface: print paniced surface_id

commit 705b2237ec694ac26b3fe4b66c945706ea4cdd31
Author: Alon Levy <alevy at redhat.com>
Date:   Wed Jun 22 13:43:13 2011 +0200

    server/red_worker: no panic on double destroy primary

commit b757ee2cf4c01cfc0272ef1d3418e972e55a69f9
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 13:42:03 2011 +0300

    server/red_worker: DEBUG_CURSORS
    
    Add cursor allocation debugging code that is turned off as long as
    DEBUG_CURSORS is not defined.

commit acc9ce1f665d0b874f230c676ff1a3feb536e36f
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Sun Apr 24 12:03:28 2011 +0300

    spice/red_worker.c: make dictionary and cache different per client
    
    There is no inter-client shared dictionary and cache yet.
    
    At this point the display channel can be used by multiple clients.
    
    You can still crash on lack of Drawables or CursorItems due to the slower
    clients pipe growing uncontrollably.

commit 451f108fc61100d3aae5467a15323dfa9431e852
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 12:00:43 2011 +0300

    server/red_worker: on_new_display_channel_client: push ack, cleanup
    
    small cleanup patch, only functional change is sending a set ack message.

commit 317c15ff7a74564e041cc717e22bc8ab8316b6ac
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 09:44:21 2011 +0300

    server/red_worker: add cursor_channel_client_disconnect
    
    makes RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT disconnect only a
    single client.

commit 9468ffecd6fbfacf6bc2931106e3d1be46e397f5
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 09:43:35 2011 +0300

    server/red_worker: remove forced disconnect on connect

commit 93c807dd887351cf43b35a324be0b19345def533
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Tue Aug 2 11:01:16 2011 +0300

    server/red_worker.c: fix CursorPipeItem leak
    
    CursorPipeItems and their corresponding cursor_item were not
    freed when they were removed from the pipe without sending them.
    In addition cursor_channel_hold_pipe_item used wrong conversion
    to (CursorItem*) for a (CursorPipeItem*).

commit 0d41b6c1f4a59d1098a84f26b8820803b4d0e80f
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 13:39:41 2011 +0300

    server/red_worker: split cursor pipe item from cursor item
    
    Required to support multiple clients.
    Also changes somewhat the way we produce PIPE_ITEM_TYPE_LOCAL_CURSOR. Btw,
    I haven't managed to see when we actually produce such an item during my
    tests.
    
    Previously we had a single pipe item per CursorItem, this is impossible
    with two pipes, which happens when we have two clients.

commit cd1d15b2f9ffecf72071972620db4b9263d608ee
Author: Alon Levy <alevy at redhat.com>
Date:   Fri Apr 22 23:04:27 2011 +0300

    server/red_worker: whitespace fixes

commit aba4310dd88a456fdc07c0dc9ffcbd053c6b79cc
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 10:31:41 2011 +0300

    server/reds: add RedsState.allow_multiple_clients
    
    Currently set by environment variable SPICE_DEBUG_ALLOW_MC (any value means
    to allow multiple connections). Later will be set by spice api from qemu.

commit 80321ece370851f3a3ef34db0e7ed812ff911695
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Tue Aug 2 09:46:46 2011 +0300

    server/red_worker.c: fix DrawablePipeItem leak
    
    DrawablePipeItems were not freed when they were removed from the
    pipe without sending them
    
    TODO: squash

commit b7a83c3024b1dcc42b9ae29ff5361ac975736003
Author: Alon Levy <alevy at redhat.com>
Date:   Wed Apr 13 09:24:31 2011 +0300

    server/red_channel: introduce client ring in RedChannel (+Drawable pipes and glz rings - split)
    
    TODO resplit red_worker stuff:
     things missing / not done right in red_worker:
      * StreamAgents are in DCC - right/wrong?
      * GlzDict is multiplied - multiple compressions.
    
    main_channel and red_worker had several locations that still accessed rcc
    directly, so they had to be touched too, but the changes are minimal.
    
    Most changes are in red_channel: drop the single client reference in RedChannel
    and add a ring of channels.
    
    We still are missing:
     * remove the disconnect calls on new connections

commit 1f85d6a49f666bd40c3124e3650b2f731aa5c926
Author: Alon Levy <alevy at redhat.com>
Date:   Wed Apr 13 08:52:44 2011 +0300

    server/red_channel: add pipe_size helpers

commit 9e258bda64f76a84ba596939aea9524abfb35da2
Author: Alon Levy <alevy at redhat.com>
Date:   Wed Apr 13 00:35:20 2011 +0300

    server/red_worker: remove more direct access to RedChannelClient.rcc

commit 31c70bb539e0c6a936f2f4ac98f9f8efe51895d1
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Thu Jul 14 08:58:39 2011 +0300

    server/red_worker.c moved free_compressed_buf from dcc to dc (common pool to all clients). TODO: squash

commit ec77f4f239aad3def1a0cd0a0d5f09748d7e7835
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Tue Aug 2 11:57:19 2011 +0300

    server/red_worker.c: fix not setting cursor_channel_client.common.worker
    TODO: squash

commit 1904a52bc1ceccc2f4a9d20dc64a6ae9d602a3e9
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Jul 3 18:56:33 2011 +0200

    server/red_worker: multiple client support (temp - not working)
    
    Temp because this is in the middle of using a single surfaces and current tree
    for all pipes. This means that each Drawable,StreamAgent needs to reference multiple pipes.
    
    Original commit message before rebasing
    ----
    
    Split both display and cursor channels to a client part and channel part.
    
    Introduce DisplayChannelClient, CursorChannelClient, CommonChannelClient.
    don't disconnect channel on client disconnect.
    Move all caches to the ChannelClient's.
    
    Remove reference counting of the channel - need to split this to a separate
    patch. The rationalization for this:
    /* TODO: Why do we reference count the listener?
     * really - what's the lifecycle of a listener? isn't it from peer connection
     * until removal? the drawable's etc. have a valid lifetime outside of this, but
     * isn't the listener's lifetime exactly this?
     * This was meant to allow deletion of the display_channel itself - but now
     * we don't actually ever delete that.
     * */
    
    No new functionality introduced.
    
    TODO: fix crash:
    Still have the possibility of crashing if too many disconnections happen at
    once. Noticed that this happens if we call disconnect with two different channel
    clients pointing to the same channel. should make sure the channel destruction
    happens from a single thread? should only happen from main thread. check
    by printing pthread_self.

commit de06159eab9e6adb46c45cdcab9ecb514f3b5ba0
Author: Alon Levy <alevy at redhat.com>
Date:   Thu May 5 12:49:35 2011 +0300

    server/red_worker: cleanup

commit 2948e11d6a89705ec6155fb3d3634ce8e970449c
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 23:58:52 2011 +0300

    server/smartcard: support multiple clients
    
    each client supplying a smartcard channel gets it's own smartcard. If
    there are not enough smartcards provided by the server (read: qemu)
    then it will be as though there are none.
    
    currently disabled - later patches that enable smartcard don't make
    this channel available to any but the first client.

commit dcd1eabadb34c584a08b6dc8980960effb424a29
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 23:51:14 2011 +0300

    server/red_tunnel_worker: trivial multi client support
    
    s/TunnelChannel/TunnelChannelClient/
    
    That's about it.  this is probably the wrong way to do it. Not tested
    at all. What do we want, a separate interface per client? same interface
    for all clients? probably the later. This doesn't do that. Not tested,
    so probably doesn't even work.
    
    changes red_channel_pipe_item_is_linked to red_channel_client_pipe_item_is_linked,
    since tunnel channel is the only user, must be done in patch to not break compilation.

commit f2486b6bf47ee05f630cf6ec8094586025d5cd6e
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 22:51:54 2011 +0300

    server/inputs_channel: support multiple clients
    
    from server events are broadcast - leds change. The rest is client
    to server, so it is just passed on.

commit 40865e43cd250a657e78fd1b5a6905a321fad8a4
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 22:29:58 2011 +0300

    server/main_channel: support multiple clients
    
    The main channel deals with connecting new clients, announcing mouse mode
    changes, and the agent channel. The implementation is currently done without
    any changes to the protocol, so everything has to be either broadcast or
    to a specific client.
    
     channels list - specific client
     mouse mode - broadcast
     agent - broadcast
     notify - broadcast (should have two modes, and use the appropriate)
    
    Notable TODOs:
     * migration testing
     * agent tokens are wrongly sent (or did I fix that? check)

commit 7478cad0d2a19ae7618016b379529bcc6f287084
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 21:44:16 2011 +0300

    server/red_channel: introduce pipes functions
    
    Introduce functions to add (via producer method) the same item to multiple
    pipes, all for the same channel.
    
    Note: Right now there is only a single channel, but the next patches will do the
    per-channel breakdown to channel and channel_client before actually introducing
    a ring in RedChannel, this makes it easier to make smaller changes - the
    channel->rcc link will exist until removed in the ring introducing patch.

commit 340cf128ca3492f699e7f2414facd9ee3ef83375
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 21:42:05 2011 +0300

    server/red_channel: ignore error if already shutdown
    
    on red_channel_peer_on_incoming_error, if we are already shutdown, do not
    call the channel's error handler. Since the channel has been shutdown, we
    assume this is a second or later error, and handling has already occured.

commit 379934993ebb2fcc1a86bfb00c89a216d1c484ee
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 20:58:01 2011 +0300

    server/main_channel: move connection_id from reds
    
    Expose additional api to find a client given a connection_id. The connection_id
    is first set when the first channel connects, which is the main channel.
    It could also be kept in the RedClient instead, not sure.
    
    TODO:
     multiple todo's added for multiclient handling. I don't remember why
     I wrote them exactly, and besides if I did any migration tests. So: TODO.

commit f14bb1ea46adeb524d248e30ee7160b9af3829e2
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 18:54:51 2011 +0300

    server/main_channel: move ping here from reds.
    
    cleanup only. Note that the ping function is half used since the opt parameter
    stopped being called with anything but NULL, should be returned at some point,
    specifically when we drop the 250kbyte ping on start and do a continuous check
    for latency and bandwidth.
    
    See:
     81945d897 - server: add new vd interface QTerm2Interface, Yaniv Kamay
      introducing the usage of ping with a non NULL opt
     3f7ea8e7a - zap qterm interfaces, Gerd Hoffman
      removing it

commit ad2dc48eaa0d2f017a7876fc00e5b81830df44e0
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 21:11:20 2011 +0300

    server/main_channel: move latency and bitrate to channel client
    
    They were globals before. This introduces api for other channels
    to query the low bandwidth status. The queries themselves are still done
    from the wrong context (channel and not channel client) but that's because
    the decoupling of channel and channel client will be done in the following
    patches.
    
    Note that snd_worker.c got two copied function declarations that belong to
    main_channel.h but can't be easily dragged into snd_worker.c since it still
    uses it's own RedChannel struct.

commit f95634035ab34d48fac10e7a42918579ecfc9af0
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 24 10:32:10 2011 +0300

    server/reds: add concept of secondary channels
    
    Secondary channels are those that don't support multiple clients. The
    support added in this patch just doesn't let the second or more connected
    client receive the unsupported channels in the channels list sent by the
    server to the client. This doesn't handle the situation where:
    
    client A connects (gets all channels)
    client B connects (gets supported multiple client channels)
    client A disconnects (Suboptimal 1: B doesn't get new channels at this point)
    client C connects (Suboptimal 2: C doesn't get the full list of channels, but
    the partial one)
    
    Specifically the channels that only support a single client are:
     sound (both playback and record channels)
     smartcard
     tunnel

commit 03f2a7732feafed80217d5b6e91b9209926c037b
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Apr 11 12:44:00 2011 +0300

    server: Add RedClient
    
    That means RedClient tracks a ring of channels. Right now there will be only
    a single client because of the disconnection mechanism - whenever a new
    client comes we disconnect all existing clients. But this patch adds already
    a ring of clients to reds.c (stored in RedServer).
    
    There is a known problem handling many connections and disconnections at the
    same time, trigerrable easily by the following script:
    
    export NEW_DISPLAY=:3.0
    
    Xephyr $NEW_DISPLAY -noreset &
    for ((i = 0 ; i < 5; ++i)); do
        for ((j = 0 ; j < 10; ++j)); do
            DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests &
        done
        sleep 2;
    done
    
    I fixed a few of the problems resulting from this in the same patch. This
    required already introducing a few other changes:
     * make sure all removal of channels happens in the main thread, for that
     two additional dispatcher calls are added to remove a specific channel
     client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and
     RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT).
     * change some asserts in input channel.
     * make main channel disconnect not recursive
     * introduce disconnect call back to red_channel_create_parser
    
    The remaining abort is from a double free in the main channel, still can't
    find it (doesn't happen when running under valgrind - probably due to the
    slowness resulting from that), but is easy to see when running under gdb.

commit bbfb717acf2706b3a29abbc7494f51193dd1d271
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 21:51:58 2011 +0300

    server/main_channel+reds: make main_channel_init return MainChannelClient
    
    This makes it easier to introduce RedClient in the next patch.

commit 9468473c769c1a01044cf09d09b0103133e3695e
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 20:17:39 2011 +0300

    server/red_worker: release PIPE_ITEM_TYPE_VERB in display channel
    
    We send a SPICE_MSG_DISPLAY_MARK verb.

commit 73e71d90597a0a7a403869f5d6211996c597051f
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 20:03:11 2011 +0300

    server/red_client: clear pipe on disconnect

commit c3b76a3a375e2ba7e01246abc4c8b76619cc7eff
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 20:02:50 2011 +0300

    server/red_channel: workaround for fast client disconnect bug (TODO - real fix)

commit 86b5633765b6dd5badfb0c1fa8c50f5c1a6853e7
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Apr 10 18:18:11 2011 +0300

    server/main_channel: use MainChannel in sig
    
    use MainChannel* instead of Channel* for a many functions in main_channel.h
    (affects main_channel.c and reds.c).
    
    some one liner fixes are hidden in here too.

commit 938bf3ccfdcbe7a30b4be01da0d4fc71c47bc7aa
Author: Alon Levy <alevy at redhat.com>
Date:   Sat Apr 2 12:54:52 2011 +0300

    server: move pipe from RedChannel to RedChannelClient
    
    Another cleanup patch, no change to behavior (still one client, and it
    disconnects previous client if any).
    
    The implementation for multiple client is straightforward: the pipe
    remains per (channel,client) pair, so it needs to move from the RedChannel
    that to RedChannelClient. Implementation using a single pipe with multiple
    consumers (to reflect different latencies) doesn't fit well with pipe rewriting
    that is used by the display channel. Additionally this approach is much simpler
    to verify. Lastly it doesn't add considerable overhead (but see the display
    channel changes in a later patch for a real place to rethink).
    
    This patch is just technical, changing signatures to reflect the first
    argument (oop style) so red_channel becomes red_channel_client. Some places
    may seem odd but they should be fixed with later comits where the channels
    grow to support multiple clients.
    
    Sound (playback/record) channels are the only ones not touched - this is
    consistent with previous patches, since they have been left out of the
    RedChannel refactoring.  That is left as future work. (note that they don't use
    a pipe, which was the reason for not refactoring).

commit c1226aef31cfaf85f6ec7b2bbcb38dc1ebba1d8c
Author: Alon Levy <alevy at redhat.com>
Date:   Mon Nov 22 16:56:58 2010 +0200

    server/red_worker: introduce {display,cursor}_is_connected
    
    Instead of checking for worker->{display,cursor}_channel directly.

commit 760238e61dfeadfef2cea6c5b99a1dfc93784817
Author: Alon Levy <alevy at redhat.com>
Date:   Sat Nov 13 13:23:02 2010 +0200

    server/red_channel (all): introduce RedChannelClient
    
    This commit adds a RedChannelClient that now owns the stream connection,
    but still doesn't own the pipe. There is only a single RCC per RC
    right now (and RC still means RedChannel, RedClient will be introduced
    later). All internal api changes are in server/red_channel.h, hence
    the need to update all channels. red_worker.c is affected the most because
    it makes use of direct access to some of RedChannel still.
    
    API changes:
    
     1. red_channel_client_create added.
      rec_channel_create -> (red_channel_create, red_channel_client_create)
     2. two way connection: rcc->channel, channel->rcc (later channel will
      hold a list, and there will be a RedClient to hold the list of channels
      per client)
     3. seperation of channel disconnect and channel_client_disconnect

commit 0585075ddf46445df6fd69d0ae3525a80883db4e
Author: Alon Levy <alevy at redhat.com>
Date:   Thu Mar 24 18:17:17 2011 +0200

    server/red_worker: drop red_pipe_add_tail, use red_channel_pipe_add_tail
    
    The only difference between them being that the later also does a push.
    I don't believe that to be a problem, but if it does I can always introduce
    a push'less version.

commit 225766af4d5f95e8e663619bf63f48ead38d9e19
Author: Alon Levy <alevy at redhat.com>
Date:   Thu Mar 24 16:41:02 2011 +0200

    server/red_channel: renames to use _proc postfix consistently
    
    rename types - we use _proc suffix mostly to indicate function pointer types,
    use it for some function pointers that were missing it.
    
    s/channel_handle_migrate_flush_mark/channel_handle_migrate_flush_mark_proc/
    s/channel_handle_migrate_data_get_serial/channel_handle_migrate_data_get_serial_proc/
    s/channel_handle_migrate_data/channel_handle_migrate_data_proc/

commit 96a0013794c7ecd9f5dbfdfb99a829d21fce58ab
Author: Alon Levy <alevy at redhat.com>
Date:   Sat Jul 2 04:23:45 2011 +0200

    spice.proto: add comment for origin of STYLED and START_WITH_GAP

commit 781704b4c2c638285e5f15c6af14e14b25c355d2
Author: Alon Levy <alevy at redhat.com>
Date:   Sat Jul 2 04:18:54 2011 +0200

    server/red_worker: explicitly include unistd and errno

commit 0e96fa8bf641b0b1d015b85e694cdd2b6c985e08
Author: Alon Levy <alevy at redhat.com>
Date:   Tue Aug 9 23:07:39 2011 +0300

    common: introduce red_printf_debug

commit d92b05548a3fb42983ff4bf8b2f17ff39366f7e6
Author: Alon Levy <alevy at redhat.com>
Date:   Fri Aug 12 21:28:28 2011 +0300

    tests/migrate.py: add --vdagent
    
    Adds the required options to provide a vdagent to the guest in both source and target qemu
    instances.
    
    This will be the last update of the in spice git tests directory, I've moved those tests
    to the repository spice-tests. The longer term goal remains autotest integration, but since
    this test (and some minor others for qemu) need a home it is:
    
    http://cgit.freedesktop.org/~alon/spice-tests/
    
    (I'm reluctant to put it under spice/ because of my wish to go to autotest, but still, there
    they are. Nothing as permanent as the temporary).
    
    Independent (of external modules, i.e. qemu) tests (server/tests) should remain in tree.

commit 29342145ecbb783e2724d90860e1668e2c0606f3
Author: Yonit Halperin <yhalperi at redhat.com>
Date:   Thu Aug 4 14:00:44 2011 +0300

    server/red_worker.c: fix - locking the wrong mutex when releasing glz dict

commit 41837ecfffa3b89551b83cfd11f0d7df3519853b
Author: Alon Levy <alevy at redhat.com>
Date:   Sun Aug 7 10:26:45 2011 +0300

    server/tests/test_display_base: fix compile

commit 7f1f658fedfa6f63b99329649fd3859edccd2f96
Author: Alon Levy <alevy at redhat.com>
Date:   Tue Aug 9 13:16:27 2011 +0300

    server/tests/migrate.py: make executable

commit d97b17c2b6a458ace82b732a439ca92bf55452aa
Author: Marc-André Lureau <marcandre.lureau at gmail.com>
Date:   Thu Jul 28 18:01:53 2011 +0200

    RFC: client/x11: reuse existing platform_win
    
    Each time a {Dynamic,MultyMon}Scren is created, a new platform_win is
    created to receive the notifications from X11. This looks very
    suspicious already. Since I am not a xlib expert, I suppose that each
    window will receive X11 events.
    
    Whenever XRR ScreenChangeNotify event is received (caused by external
    process), init_monitors() is called and this will recreate new
    platform_wins. And sometime, this event happen in a loop and Xorg
    takes 100% cpu. If only one platform_win is used, the loop doesn't
    happen for me, but seem to still happen for others.
    
    Related bug:
    https://bugzilla.redhat.com/show_bug.cgi?id=692833



More information about the Spice-commits mailing list