OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


> > +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)?


> 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 ...

> > +\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/


> > +\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

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 ...


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]