vnc: 0.950
graphic: 0.915
performance: 0.806
device: 0.763
network: 0.705
semantic: 0.694
PID: 0.681
ppc: 0.632
peripherals: 0.629
socket: 0.600
operating system: 0.594
debug: 0.572
boot: 0.571
architecture: 0.568
risc-v: 0.550
x86: 0.534
i386: 0.520
permissions: 0.517
KVM: 0.516
mistranslation: 0.516
hypervisor: 0.508
VMM: 0.505
kernel: 0.480
TCG: 0.462
register: 0.454
files: 0.453
user-level: 0.433
arm: 0.405
assembly: 0.389
alpha: 0.379
virtual: 0.376

[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 ?