Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio input device specification.

[Gerd Hoffmann]

  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.
> 
> 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}.
> 
> 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
> 
> s/send/sent/

Fixed.

> > +\begin{lstlisting}
> > +struct virtio_input_event {
> > +   le16 type;
> > +   le16 code;
> > +   le32 value;
> > +};
> > +\end{lstlisting}
> 
> 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