From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSOi8-0004vP-6Q for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:08:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSOi1-00012x-WF for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:08:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSOi1-00011m-PR for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:08:09 -0400 Message-ID: <1410520083.30411.11.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Fri, 12 Sep 2014 13:08:03 +0200 In-Reply-To: <5411BFF9.9030102@redhat.com> References: <1410448173-12960-1-git-send-email-kraxel@redhat.com> <1410448173-12960-3-git-send-email-kraxel@redhat.com> <5411BFF9.9030102@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Dave Airlie , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org Hi, > > +++ 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. Added copyright for now. Dunno about license, IIRC GPLv2 isn't good for text, suggestions? > > + 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? enum virtgpu_formats (text updated). > > + 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. Correct. Text updated. > Are there restrictions against rectangles that overlap beyond screen > boundaries? Backing resource must cover the scanout completely. With multiple heads (and therefore multiple scanouts) it is legal for the scanouts to overlap or even be identical (=> screen mirroring). Text updated. thanks, Gerd