2007/10/3, Daniel P. Berrange <[EMAIL PROTECTED]>: > > > The memset calls in that patch are bogus & not correctly fixing the buffer > update problem. You're merely setting the 'old data' to have pixel value > 42 - if the guest OS framebuffer happens to also have aras with pixel > value > of 42 too, the frame buffer will still not correctly update. The root > problem is overly-aggressive update minimization logic in > vnc_update_client. > This is in turn flawed beause the dirty_row aray is trying to encode two > separate concepts - areas which are dirty, and areas which need to be > sent to the client. The latter are a superset of the former, but the code > in vnc_update_client minimizes based on dirtiness, so updates will get > missed out. Setting the old data to 42 merely changes which areas will get > missed updates.
Agreed. I just used the same hack that is scattered around several other places to make a patch quickly. The QEMU code in Xen has added a update_row field, separate from the > dirty_row > field. Thus after a resize it can update the entire framebuffer, > regardless > of whether QEMU's copy of the framebuffer is dirty wrt to the guest copy. I think that VNC server needs a deep rework, as several qemu related projects have done, but meanwhile correcting bugs with small non-intrusive patches may be the way to go. Edu.
