[Top][All Lists]

[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

From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH v2 10/12] spice/gl: create dummy primary surface (RfC)
Date: Mon, 23 May 2016 16:03:55 +0200


On Mon, May 23, 2016 at 3:52 PM, Gerd Hoffmann <address@hidden> 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?


Marc-André Lureau

reply via email to

[Prev in Thread] Current Thread [Next in Thread]