Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

[Michael S. Tsirkin]

On Thu, Mar 19, 2015 at 10:13:10AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> This patch adds a virtio driver for input devices.
> 
> Specification:
>   https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input
>   https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007


OK, I don't know which thread should I use for spec discussions.
Referring to that:

	"See file:///usr/include/linux/input.h."

Is likely not present on many systems, or might not include
the info you refer to.

 "type, code and value are filled according to the linux input layer
 (evdev) interface"

Which version?  How will non-linux guests know what to implement?


> 
> Qemu patches;
>   https://lists.gnu.org/archive/html/qemu-devel/2015-03/threads.html#03973
> 
> Gerd Hoffmann (1):
>   Add virtio-input driver.
> 
>  drivers/virtio/Kconfig            |  10 ++
>  drivers/virtio/Makefile           |   1 +
>  drivers/virtio/virtio_input.c     | 313 ++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/virtio_ids.h   |   1 +
>  include/uapi/linux/virtio_input.h |  65 ++++++++
>  5 files changed, 390 insertions(+)
>  create mode 100644 drivers/virtio/virtio_input.c
>  create mode 100644 include/uapi/linux/virtio_input.h
> 
> -- 
> 1.8.3.1

Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

[Gerd Hoffmann]

On Do, 2015-03-19 at 14:35 +0100, Michael S. Tsirkin wrote:
> On Thu, Mar 19, 2015 at 10:13:10AM +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > This patch adds a virtio driver for input devices.
> > 
> > Specification:
> >   https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input
> >   https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007
> 
> 
> OK, I don't know which thread should I use for spec discussions.
> Referring to that:
> 
> 	"See file:///usr/include/linux/input.h."
> 
> Is likely not present on many systems, or might not include
> the info you refer to.

Dunno what the best way to deal with it is.  Link to the version online
@ kernel.org instead maybe?

>  "type, code and value are filled according to the linux input layer
>  (evdev) interface"
> 
> Which version?

Latest.  As far I know there never ever have been incompatible changes
to the interface, and given this is userspace/kernel abi I don't expect
that to happen in the future.

>   How will non-linux guests know what to implement?

There are some docs on the linux input layer and evdev events in
Documentation/input/ in the kernel tree.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

[Michael S. Tsirkin]

On Thu, Mar 19, 2015 at 03:46:44PM +0100, Gerd Hoffmann wrote:
> On Do, 2015-03-19 at 14:35 +0100, Michael S. Tsirkin wrote:
> > On Thu, Mar 19, 2015 at 10:13:10AM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > This patch adds a virtio driver for input devices.
> > > 
> > > Specification:
> > >   https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input
> > >   https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007
> > 
> > 
> > OK, I don't know which thread should I use for spec discussions.
> > Referring to that:
> > 
> > 	"See file:///usr/include/linux/input.h."
> > 
> > Is likely not present on many systems, or might not include
> > the info you refer to.
> 
> Dunno what the best way to deal with it is.  Link to the version online
> @ kernel.org instead maybe?
> 
> >  "type, code and value are filled according to the linux input layer
> >  (evdev) interface"
> > 
> > Which version?
> 
> Latest.  As far I know there never ever have been incompatible changes
> to the interface, and given this is userspace/kernel abi I don't expect
> that to happen in the future.

More events are added though, are they not? And distros backport rundom
subsets.
So I worry: what happens e.g. if you migrate between hosts which expose
slightly different subsets of events?
Might e.g. a button get stuck because button-press event was
sent but button-release wasn't?


> >   How will non-linux guests know what to implement?
> 
> There are some docs on the linux input layer and evdev events in
> Documentation/input/ in the kernel tree.
> 
> cheers,
>   Gerd



-- 
MST

Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

[Michael S. Tsirkin]

On Thu, Mar 19, 2015 at 03:46:44PM +0100, Gerd Hoffmann wrote:
> On Do, 2015-03-19 at 14:35 +0100, Michael S. Tsirkin wrote:
> > On Thu, Mar 19, 2015 at 10:13:10AM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > This patch adds a virtio driver for input devices.
> > > 
> > > Specification:
> > >   https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input
> > >   https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007
> > 
> > 
> > OK, I don't know which thread should I use for spec discussions.
> > Referring to that:
> > 
> > 	"See file:///usr/include/linux/input.h."
> > 
> > Is likely not present on many systems, or might not include
> > the info you refer to.
> 
> Dunno what the best way to deal with it is.  Link to the version online
> @ kernel.org instead maybe?
> 
> >  "type, code and value are filled according to the linux input layer
> >  (evdev) interface"
> > 
> > Which version?
> 
> Latest.  As far I know there never ever have been incompatible changes
> to the interface, and given this is userspace/kernel abi I don't expect
> that to happen in the future.
> 
> >   How will non-linux guests know what to implement?
> 
> There are some docs on the linux input layer and evdev events in
> Documentation/input/ in the kernel tree.
> 
> cheers,
>   Gerd


Also, the spec needs to be rewritten a bit more formally,
with conformance clauses separated from freetext description,
and linked to from appropriate section.

" motion events are send from the device" send->sent

-- 
MST

Re: [Qemu-devel] [PATCH 0/1] Add virtio-input driver.

[Paolo Bonzini]

On 19/03/2015 17:33, Michael S. Tsirkin wrote:
> On Thu, Mar 19, 2015 at 03:46:44PM +0100, Gerd Hoffmann wrote:
>> Latest.  As far I know there never ever have been incompatible changes
>> to the interface, and given this is userspace/kernel abi I don't expect
>> that to happen in the future.
> 
> More events are added though, are they not? And distros backport rundom
> subsets.
> So I worry: what happens e.g. if you migrate between hosts which expose
> slightly different subsets of events?
> Might e.g. a button get stuck because button-press event was
> sent but button-release wasn't?

I think this is the same as SCSI.  You can migrate between hosts which
expose slightly different command sets.

Paolo