Re: [virtio-dev] [PATCH 2/2] Add GPU device type.

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> for this reason, I think it's best to do:
> 
> struct virtgpu_command_hdr {
> 	 +     le32 type;
>  	 +     le32 flags;
>  	 +     le64 fence_id;
> }
> 
> and have each command include that implicitly or explicitly.

Makes sense.

> So I assume each command has an out buffer
> using virtgpu_cmds format, followed by in buffer
> using virtgpu_response?

Not all commands return a response (although maybe dave changes that
while removing the event queue).  The commands use some bits for tagging
(that isn't included in the spec patch, need to fix that for the next
revision).  Bit 31 is set for 3D commands.  Bit 30 is set for commands
returning a response.

But, yes command goes into the out buffer and response into the in
buffer.

> > per vq entry. The cursor is just
> > +a standard 2D resource that is 64x64 sized. Transfers are used to
> > +upload the cursor contents.
> 
> which way is up? just say to load from ... to ...

guest -> host (or driver -> device, which seems to be used in virtio
specs)

> > +
> > +For cursor movement, only \field{cursor_x} and \field{cursor_y} need to be
> > +updated.
> > +
> > +For a cursor update where the guest has transferred a new cursor into
> > +the resource, \field{cursor_hot_x}, \field{cursor_hot_y} and
> > +\field{cursor_id} should be updated and \field{generation_count}
> > +should be increased by one,
> 
> you mean each successive command as compared to the previous one?

As I understand it:  You create one (or more) cursor resources using
normal command queue commands.  Then you'll set cursor_id to the
resource id you want use as cursor, fill the other fields.
generation_count being incremented (relative to the previous command)
implies the cursor sprite needs to be reloaded.  same generation_count
indicates only the position (x & y) has changed.  Correct dave?

cheers,
  Gerd