Re: [Qemu-devel] virtio-input questions

Re: [Qemu-devel] virtio-input questions

[Jiri 'Ghormoon' Novak]

Hi,

resending this, seems you did a typo when CCing qemu-devel and I've just 
blindly replied-all and got a bounce, sorry for doubled mail, I keep you 
both in recipients so we don't have multiple threads later.

Gh.

Jiri 'Ghormoon' Novak wrote:
> Hi
>
> Gerd Hoffmann wrote:
>>    Hi,
>>
>> [ Cc'ing qemu-devel + alex ]
>>
>>> when discussing my attempts at passthrough of ps2 input, I've been
>>> pointed towards your work on virtio-input.
>>> I've got a question:
>>> Did you think about attaching those to standard qemu input, so even
>>> hosts without virtio drivers can use them? It would be great help if
>>> keyboard could be used like that.
>> You mean grab events from /dev/input/event$nr and feed them into the
>> qemu input system, so they show up on whatever emulated input device the
>> guest happens to have?  Should be doable for keyboard and mouse.  Not so
>> easy for tablet/touchscreen.
>>
>> Might be useful for people doing vga pass-through using vfio too,
>> keyboard/mouse input is a constant source of trouble there.
>>
> Exactly that's my use-case. I'm doing VGA-passthrough of my only 
> (laptop) VGA and passing in the laptop keyboard too (they're still ps2 
> keyboards technically, not usb, that would be fairly easy).
>
> I'm curretly using a hack that I got here: 
> http://lists.xen.org/archives/html/xen-devel/2010-03/msg01292.html and 
> heavily modified it for qemu 2. But I've done it very wrong back then 
> - hacking pckbd.c to give me the pointer to showel in input from 
> /dev/tty0.
> I've been discussing this on #qemu and got directed to look at 
> ui/curses.c, which is likely closest to what I need to do, but only 
> for input and more lowlevel. They also pointed me to your work, so 
> I've asked about that, if I can use it.
> Seems I'll try to start from the curses.c then, if that's better way 
> (my knowledge of qemu codebase is zero and I'm not a good developer 
> either, but I may try in my free time since I need this and I'd like 
> to see it upstream - there are more people trying vga passthrough who 
> possibly need this :)) At least keyboard, mouse is nice to have, but 
> that can be done with the virtio-input, it's not crucial eg. during 
> installation where you may not have those drivers.
>
>>> Is there any technical reason it can't/shouldn't be done with your 
>>> devices?
>> That wouldn't be related to virtio-input at all, and also probably
>> wouldn't be able to share much code with virtio-input-host as qemu would
>> have to interpret the linux input layer events then instead of passing
>> them through to the guest without looking at them much.
>>
>>> also, do you have any public testing VMs, that are known to work with
>>> synaptics touchpad? I'm trying out the virtio devices, I've managed to
>>> get trackpoint working, but touchpad kills the guest X. I'd like to 
>>> make
>>> sure the problem is guest-side. If you don't have one, I'll try to make
>>> more experiments myself to see where the problem is.
>> I'd suspect X in the guest is surprised to find the touchpad attached
>> via virtio instead of ps/2, possibly because it tries to configure the
>> touchpad and doesn't find the knobs needed to do so ...
> I was just wondering if you don't have a bunch of testing VMs that 
> you've already used for this to quickly rule out one side (host or 
> guest). I've tested it on debian only so far (jessie-backports 
> kernel), I may install few more to see if it's not some unrelated bug 
> (it crashes on floating point exception in synaptics driver).
>>
>> cheers,
>>    Gerd
>>
> Thanks for the reply,
> Gh.
>

Re: [Qemu-devel] virtio-input questions

[Gerd Hoffmann]

  Hi,

> > Seems I'll try to start from the curses.c then, if that's better way 
> > (my knowledge of qemu codebase is zero and I'm not a good developer 
> > either, but I may try in my free time since I need this and I'd like 

I wouldn't bother with curses.  Better grab input events directly at the
source, like virtio-input-host does.  Check out
hw/input/virtio-input-host.c, or https://www.kraxel.org/cgit/input/
(probably gives a better idea how to interpret the linux input layer
events).

Also note that hw/input/virtio-input-hid.c has a qcode -> linux mapping
table, which should be usable to generate a reverse mapping.  You'll
need that to feed linux keyboard events into the qemu input code.

> > to see it upstream - there are more people trying vga passthrough who 
> > possibly need this :)) At least keyboard, mouse is nice to have, but 
> > that can be done with the virtio-input, it's not crucial eg. during 
> > installation where you may not have those drivers.

If virtio-input works for the mouse it should work equally well for
keyboard.  Guest drivers are upstream in kernel 4.1 & newer.  Fedora 22
should work once you've updated the kernel (shipped with kernel 4.0.x,
now at 4.2.x).  With the just released Fedora 23 virtio-input should
even work on the install media (didn't test that yet though ...).

> > I was just wondering if you don't have a bunch of testing VMs that 
> > you've already used for this to quickly rule out one side (host or 
> > guest).

I'm using standard fedora install, without any special tweaks (other
than a self-compiled kernel in the early days, but even that isn't
needed any more).

cheers,
  Gerd

Re: [Qemu-devel] virtio-input questions

[Jiri 'Ghormoon' Novak]

Hi,

Gerd Hoffmann wrote:
>    Hi,
>
>>> Seems I'll try to start from the curses.c then, if that's better way
>>> (my knowledge of qemu codebase is zero and I'm not a good developer
>>> either, but I may try in my free time since I need this and I'd like
> I wouldn't bother with curses.  Better grab input events directly at the
> source, like virtio-input-host does.  Check out
> hw/input/virtio-input-host.c, or https://www.kraxel.org/cgit/input/
> (probably gives a better idea how to interpret the linux input layer
> events).
>
> Also note that hw/input/virtio-input-hid.c has a qcode -> linux mapping
> table, which should be usable to generate a reverse mapping.  You'll
> need that to feed linux keyboard events into the qemu input code.
Maybe I've formulated it bit wrong, the part I should be taking from 
curses was mainly about how to feed it to qemu input. I'll have to look 
into that a more in detail, I don't understand it much yet :)
>>> to see it upstream - there are more people trying vga passthrough who
>>> possibly need this :)) At least keyboard, mouse is nice to have, but
>>> that can be done with the virtio-input, it's not crucial eg. during
>>> installation where you may not have those drivers.
> If virtio-input works for the mouse it should work equally well for
> keyboard.  Guest drivers are upstream in kernel 4.1 & newer.  Fedora 22
> should work once you've updated the kernel (shipped with kernel 4.0.x,
> now at 4.2.x).  With the just released Fedora 23 virtio-input should
> even work on the install media (didn't test that yet though ...).
Well, but eg. for Debian, stable doesn't have the drivers yet. You need 
a backport kernel :) Or even worse - Windows guest which won't take it 
at all yet. Or maybe others. if you're booting something in the guest 
with vga and keyboard passthrough, there's still big chance you won't 
have the keyboard working. so that's the reason to use qemu input.
And for the windows - that's a quite common reason for vga passthrough - 
you have disposable gaming VM (running on LUKS+ZFS drive and it doesn't 
complain :P)
>>> I was just wondering if you don't have a bunch of testing VMs that
>>> you've already used for this to quickly rule out one side (host or
>>> guest).
> I'm using standard fedora install, without any special tweaks (other
> than a self-compiled kernel in the early days, but even that isn't
> needed any more).
> cheers,
>    Gerd
>
>