Hi, > + /* optional */ > + void (*dpy_gl_wait_dmabuf)(DisplayChangeListener *dcl, > + QemuDmaBuf *dmabuf);
Hmm, a blocking wait isn't the best plan here, it'll stall the iothread. We already have a way to stop virtio-gpu command processing: graphic_hw_gl_block() + graphic_hw_gl_flush() graphic_hw_gl_block(true) will block virtio-gpu command processing. graphic_hw_gl_block(false) will unblock virtio-gpu command processing. graphic_hw_gl_flush() will kick virtio-gpu so it resumes command processing. I saw in patch #5 that you just do a blocking wait for the fence, which isn't fundamentally different from what graphic_hw_gl_block does, so it should be possible to make the gtk ui use that instead. You'll need an async notification for the fence then. I think you can simply poll the fence fd. Failing that you can either use a timer to check the fence or do the blocking wait in a new thread. One little detail is different with graphic_hw_gl_block: It'll send the completion no matter what, then stop fetching the next command from the queue. So that logic needs an update to also allow delaying the command completion. take care, Gerd
