Skip to content
  • Anthony Liguori's avatar
    vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) · 6baebed7
    Anthony Liguori authored
    
    
    This patch killes the old_data hack in the qemu server and replaces
    it with a clean separation of the guest-visible display surface and
    the vnc server display surface.  Both guest and server surface have
    their own dirty bitmap for tracking screen updates.
    
    Workflow is this:
    
    (1) The guest writes to the guest surface.  With shared buffers being
        active the guest writes are directly visible to the vnc server code.
        Note that this may happen in parallel to the vnc server code running
        (today only in xenfb, once we have vcpu threads in qemu also for
        other display adapters).
    
    (2) vnc_update() callback tags the specified area in the guest dirty
        map.
    
    (3) vnc_update_client() will first walk through the guest dirty map.  It
        will compare guest and server surface for all regions tagged dirty
        and in case the screen content really did change the server surface
        and dirty map are updated.
        Note: old code used old_data in a simliar way, so this does *not*
        introduce an extra memcpy.
    
    (4) Then vnc_update_cient() will send the updates to the vnc client
        using the server surface and dirty map.
        Note: old code used the guest-visible surface instead, causing
        screen corruption in case of guest screen updates running in
        parallel.
    
    The separate dirty bitmap also has the nice effect that forced screen
    updates can be done cleanly by simply tagging the area in both guest and
    server dirty map.  The old, hackish way was memset(old_data, 42, size)
    to trick the code checking for screen changes.
    
    Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
    
    
    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
    6baebed7