vnc: 0.171
graphic: 0.152
semantic: 0.127
other: 0.123
device: 0.077
PID: 0.056
performance: 0.049
boot: 0.047
permissions: 0.041
network: 0.038
debug: 0.036
socket: 0.033
files: 0.026
KVM: 0.025
debug: 0.506
vnc: 0.213
network: 0.123
graphic: 0.046
boot: 0.022
performance: 0.020
other: 0.016
files: 0.014
PID: 0.010
device: 0.008
socket: 0.006
semantic: 0.005
KVM: 0.005
permissions: 0.005

[Qemu-devel] [BUG] VNC: client won't send FramebufferUpdateRequest if job in flight is aborted

Hi Gerd, Daniel.

We noticed that if VncSharePolicy was configured with 
VNC_SHARE_POLICY_FORCE_SHARED mode and
multiple vnc clients opened vnc connections, some clients could go blank screen 
at high probability.
This problem can be reproduced when we regularly reboot suse12sp3 in graphic 
mode both
with RealVNC and noVNC client.

Then we dig into it and find out that some clients go blank screen because they 
don't
send FramebufferUpdateRequest any more. One step further, we notice that each 
time
the job in flight is aborted one client go blank screen.

The bug is triggered in the following procedure.
Guest reboot => graphic mode switch => graphic_hw_update =>  vga_update_display
=> vga_draw_graphic (full_update = 1) => dpy_gfx_replace_surface => 
vnc_dpy_switch =>
vnc_abort_display_jobs (client may have job in flight) => job removed from the 
queue
If one client has vnc job in flight, *vnc_abort_display_jobs* will wait until 
its job is abandoned.
This behavior is done in vnc_worker_thread_loop when 'if (job->vs->ioc == NULL 
|| job->vs->abort == true)'
branch is taken.

As we can see, *vnc_abort_display_jobs* is intended to do some optimization to 
avoid unnecessary client update.
But if client sends FramebufferUpdateRequest for some graphic area and its 
FramebufferUpdate response job
is abandoned, the client may wait for the response and never send new 
FramebufferUpdateRequest, which may
case the client go blank screen forever.

So I am wondering whether we should drop the *vnc_abort_display_jobs*  
optimization  or do some trick here
to push the client to send new FramebufferUpdateRequest. Do you have any idea ?