[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 10/12] spice/gl: create dummy primary surface
Re: [Qemu-devel] [PATCH v2 10/12] spice/gl: create dummy primary surface (RfC)
Mon, 23 May 2016 16:03:55 +0200
On Mon, May 23, 2016 at 3:52 PM, Gerd Hoffmann <address@hidden> wrote:
> 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?