From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60160)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZbUPC-0002H1-Hj
	for qemu-devel@nongnu.org; Mon, 14 Sep 2015 10:06:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZbUP4-0002M8-S2
	for qemu-devel@nongnu.org; Mon, 14 Sep 2015 10:06:50 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60842)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZbUP4-0002LW-Ne
	for qemu-devel@nongnu.org; Mon, 14 Sep 2015 10:06:42 -0400
Message-ID: <1442239599.13588.5.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 14 Sep 2015 16:06:39 +0200
In-Reply-To: <CAJ+F1CKywA+Y9-aJ4oK=j72VZq6BS7CX_SKqWrfZCK3o9TOWog@mail.gmail.com>
References: <CAJ+F1CKywA+Y9-aJ4oK=j72VZq6BS7CX_SKqWrfZCK3o9TOWog@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] virtio-gpu: cursor update not in sync with
	resource update
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>, QEMU <qemu-devel@nongnu.org>

  Hi,

> Afaik, the goal of the seperate cursor queue is to update cursor
> quickly (probably to give good input responsiveness). However, the
> VIRTIO_GPU_CMD_UPDATE_CURSOR references a surface that is uploaded via
> the ctrl queue. The same resource id may be reused for cursor update.
> But there is no synchronization between the two queues. So often, the
> cursor set results in last update being shown. Should the kernel wait
> for the update to finish?

Yes (for new cursors).

> But then why having 2 different queues?
> Should the update be done on the cursor queue instead? or should the
> different cursor be cached (with different id) and qemu to do the
> synchronization?

The guest can upload different cursors and then switch between them
without re-uploading and therefore without ctrl queue updates.  Thats
why they have an id in the first place ...

cheers,
  Gerd