Hi,
> >> if (!ret) {
> >> reservation_object_add_excl_fence(qobj->tbo.resv,
> >> &fence->f);
> >> virtio_gpu_object_wait(qobj, false);
> >> }
> >>
> >> before moving the cursor, shouldn't that suffi
On 15 September 2015 at 07:14, Marc-André Lureau
wrote:
> Hi
>
> On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie wrote:
>> Currently the kernel driver does this:
>>
>> ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev, qobj->hw_res_handle,
>> 0,
>>
Hi
On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie wrote:
> Currently the kernel driver does this:
>
> ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev, qobj->hw_res_handle,
> 0,
> cpu_to_le32(64),
>
On 15 September 2015 at 01:17, Marc-André Lureau
wrote:
> Hi
>
> On Mon, Sep 14, 2015 at 4:06 PM, Gerd Hoffmann wrote:
>> 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 firs
Hi
On Mon, Sep 14, 2015 at 4:06 PM, Gerd Hoffmann wrote:
> 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 ...
Ok, but the cursor id is reused most of the time. So
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
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 synchr
