[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 0/3] input: linux evdev support

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] input: linux evdev support
Date: Wed, 9 Mar 2016 22:23:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 04/03/2016 11:25, Gerd Hoffmann wrote:
>   Hi,
> This patch series adds support for reading input events directly from
> linux input devices instead of getting them from the UI (gtk/spice/...).
> This is useful if you pci passthrough your vga, because you don't need
> some otherwise dummy UI just to feed input into your guest.  Chech the
> patch #1 commit message for all the details.
> It's been a while I posted the patches last time.  Undusted them.
> Rebased to master.  Adapted to some QAPI changes.  Squashed in some
> bugfixes accumulated over time.  Applied some testing using my new
> intel test box.

This is nice! I have used virtio-input-host to do some pseudo-multiseat,
but it was only for Linux guests.

However, instead of adding a new -input-linux option, could you make it
a QOM object which implements UserCreatable?  Then you can add it with
something like "-object input-linux,path=/dev/input/input10" (perhaps
"input-evdev" would be more specific).  This has three advantages:

1) you get hotplug for free;

2) you don't add yet another option to vl.c (btw patch 2 and 3 are not
updating the docs);

3) it's easier to add more backends, though the only ones that come to
mind are rather silly (e.g. input-msmouse could take a chardev and parse
the serial mouse protocol).

If you cannot use QOM, even just using "-inputdev
[backend=]linux,path=/dev/input/input10" would provide (3), but QOM
seems superior at the cost of a little more boilerplate in ui/input-linux.c.



reply via email to

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