qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/4] virtio-input: core code & base class


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH 2/4] virtio-input: core code & base class
Date: Wed, 18 Mar 2015 16:31:53 +0100

On Mi, 2015-03-18 at 15:31 +0100, Michael S. Tsirkin wrote:
> On Wed, Mar 18, 2015 at 03:00:12PM +0100, Gerd Hoffmann wrote:
> > This patch adds virtio-input support to qemu.  It brings a abstract
> > base class providing core support, other classes can build on it to
> > actually implement input devices.
> > 
> > virtio-input basically sends linux input layer events (evdev) over
> > virtio.
> > 
> > Signed-off-by: Gerd Hoffmann <address@hidden>
> 
> Two questions before I looked at code:
> - can you do a writeup for the virtio spec?
>   might make it easier to review.

>From cover letter:

<quote>

Guest driver:
  https://www.kraxel.org/cgit/linux/log/?h=virtio-input

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

</quote>

Guess you havn't seen that (yet) because get_maintainers.pl doesn't
really work for the cover letter, only the patches, and I forgot to cc
you for the whole series.  [ anyone has a solution for this btw? ]

> - does linux need to support this?

For pass-through (patch 4) yes, emulated hid devices (patch 3) not
really.  It is linux only for now because the code simply #includes the
system header files for the linux input layer, so it wouldn't compile on
something else.

>   if yes we'll eventually want to take
>   the header from there.

Yes, we can do that, for both linux input layer and virtio-input (once
merged upstream) headers, then go build this on non-linux hosts too.

I'd suggest to do that as incremental patch, after guest driver merge.

>   maybe split out guest/host ABI?

When copying over virtio-input header from linux kernel that needs to
happen anyway.

>   also might be a good idea to make style there
>   linux-compliant (e.g. no typedefs, add typedefs
>   in another header).

Linux driver linked above already has that.

cheers,
  Gerd





reply via email to

[Prev in Thread] Current Thread [Next in Thread]