Re: [Qemu-devel] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On 09/11/2014 09:09 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  docs/specs/virtio-gpu.txt | 165 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 165 insertions(+)
>  create mode 100644 docs/specs/virtio-gpu.txt
> 
> diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt
> new file mode 100644
> index 0000000..9455383
> --- /dev/null
> +++ b/docs/specs/virtio-gpu.txt
> @@ -0,0 +1,165 @@
> +virtio-gpu specification

I know you are just following existing bad practice in this directory,
but it would be nice to declare copyright and license on this file.


> +
> +The two members events_read and events_clear are used to signal events
> +to the driver.  Currently one event is defined for a display
> +change. When a config space interrupt is received the driver should
> +read the events_read field.  The events processed should be written to
> +the events_clear field.  The device will clear the bits in events_read
> +then, mimicing write-to-clear behavior.

s/mimicing/mimicking/ (stupid English rule that any verb ending in 'ic'
becomes 'ick' when adding 'ed' or 'ing')

> +Both queues have the same format.  Each request and each response have
> +a fixed header (struct virtgpu_ctrl_hdr), followed by command specific
> +data fieds.  The separate cursor queue is the "fast track" for

s/fieds/fields/

> +The virtio-gpu is based around the concept of resources private to the
> +host, the guest must DMA transfer into these resources. This is a
> +design requirement in order to interface with future 3D rendering. In
> +the unaccelerated there is no support for DMA transfers from

s/unaccelerated/unaccelerated mode/

> +  This creates a 2D resource on the host with the specified width,
> +  height and format. Only a small subset of formats are support. The

s/support/supported/
and can you delineate that subset?


> +  This sets the scanout parameters for a single scanout. The
> +  resource_id is the resource to be scanned out from, along with a
> +  rectangle specified by x, y, width and height.

Is it worth a mention here or generically up front where 0,0 is in
relation to the screen, and in which direction positive numbers move?
I'm assuming 0,0 is top left, and larger x moves right, larger y moves down.

Are there restrictions against rectangles that overlap beyond screen
boundaries?


> +  This assign an array of guest pages (struct virtgpu_mem_entry) as

s/assign/assigns/

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]