Hi On Mon, May 23, 2016 at 3:52 PM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > Hi, > > Resuming to work on this after 2.6 freeze break ... > >> I have done some more testing and sent a series for spice-gtk fixing >> display with gl scanout-only case. And a minor patch to spice server >> to solve a cursor initialization when there is no canvas. Your series >> works ok with that, only when doing a reboot, virtio_gpu_virgl_reset() >> calls spice_qxl_gl_scanout( fd = -1), and later spice_gl_refresh() >> calls spice_qxl_gl_draw_async() and reaches the following error: >> >> (process:21117): Spice-CRITICAL **: >> red-qxl.c:900:spice_qxl_gl_draw_async: condition >> `qxl_state->scanout.drm_dma_buf_fd != -1' failed > > Hmm, that is sort-of intentional. It's valid for scanouts to not be > backed by a resource, and in that case qemu_spice_gl_scanout() calls > spice_qxl_gl_scanout() with fd=-1. Ok, then I suppose the display should be marked as non-ready, and the client should reflect that (blank display or "not ready" message) > > So, what do you think we should do here? Fix spice to handle that case? > Should qemu do something else instead? Such as not calling > spice_qxl_gl_scanout() to keep the previous dma-buf alive? I can't really make sense of a call to spice_qxl_gl_draw_async() if there is no scanout backing. So I can imagine the fix is on qemu side. Do you have an up to date branch for testing? thanks -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel