From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b03rX-0004rR-1l for qemu-devel@nongnu.org; Tue, 10 May 2016 05:21:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b03rS-0005K2-OP for qemu-devel@nongnu.org; Tue, 10 May 2016 05:21:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b03rS-0005Jn-J2 for qemu-devel@nongnu.org; Tue, 10 May 2016 05:21:50 -0400 Message-ID: <1462872107.8035.28.camel@redhat.com> From: Gerd Hoffmann Date: Tue, 10 May 2016 11:21:47 +0200 In-Reply-To: <20160509140221.GH3372@stefanha-x1.localdomain> References: <1462365524-21163-1-git-send-email-kraxel@redhat.com> <20160509140221.GH3372@stefanha-x1.localdomain> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio input device specification. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org Hi, > > +To query a specific piece of information the driver MUST set > > +\field{select} and \field{subsel} accordingly, then check \field{size} > > +to see and how much information is available. \field{size} can be > > +zero if no information is available. >=20 > Is there a particular write order that matters (subsel then select vs > select then subsel)? No. > MUST/MAY/etc statements go into \devicenormative or \drivernormative > sections. These must be referenced from conformance.tex too. Hmm, seems they are linked to section. I'd rate that particular section (device config layout) normative for both device and driver ... > > +\item[VIRTIO_INPUT_CFG_ID_NAME] > > +\field{subsel} is not used and MUST be zero. > > +Returns the name of the device, in \field{u.string}. >=20 > Is it a NUL-terminated string and does size include the NUL byte? Not NUL-terminated (in practice chances are high it actually is NUL-terminated, but that is more a side effect of the actual implementation). Length without NUL-byte obviously. Text updated. > > +\begin{enumerate} > > +\item Input events such as press and release events for keys and > > + buttons and motion events are send from the device to the driver >=20 > s/send/sent/ Fixed. > > +\begin{lstlisting} > > +struct virtio_input_event { > > + le16 type; > > + le16 code; > > + le32 value; > > +}; > > +\end{lstlisting} >=20 > Is there any provision for running out of descriptors in the eventq? I > guess the device can buffer events until the eventq has more > descriptors. Given that this is HID hopefully the event rate is low > enough that even slow guests can refill eventq in time for the next > event. An input event can have multiple eventq entries, and the input layer uses a special sync event to group them. So, a mouse move usually has three entries: One for the X axis, one for the Y axis, and the sync. The qemu implementation queues up events until it sees a sync, then goes place the whole group into the event queue. Or drops them all in case there isn't enough space. So the guest will never see a incomplete group. But that's it. No additional buffering. The event queue has 64 entries, that should be plenty given that HID is low-rate indeed. If the queue is full you likely have bigger problems than dropped input events ... cheers, Gerd