Re: [Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices

[Gerd Hoffmann]

  Hi,

> If drivers don't expect a mix of functionality, then separate IDs
> seem better.

The linux kernel can deal with it just fine.  It's just that humans are
more used to have separate devices.  And I remember back in the dark xen
days the input channel for xenfb was a unified input device which
delivered both mouse and keyboard events, and it caused some grief with
the X11 configuration.

While thinking about it:  We could certainly make this
user-configurable.  So instead of adding three new devices we just add
one with config options.  Then we'll have

  -device virtio-input-emulated-pci,kbd=on

instead of

  -device virtio-keyboard-pci

Likewise for mouse and tablet.  And it'll be possible then to just do

  -device virtio-input-emulated-pci,kbd=on,tablet=on

to get a unified device.

> OTOH an advantage to using a custom identification scheme would be
> if you want to allow a single device to change type
> dynamically.

Changing dynamically isn't going to happen.

> Or more interestingly, as we migrate from host with a mouse
> to an MT one, switch from a mouse to a touch device?

Multitouch is tricky, especially the input side.  gtk+sdl ui could work
without too much trouble.  spice+vnc need protocol extensions for that.
Not investigated yet in detail.  Guess it's a good excuse to expense a
new, shiny and multi-touch capable monitor ;)

Singletouch is easy.  We'll basically send BTN_TOUCH instead of
BTN_LEFT.  And with some additional tweaks (such as filtering out any
move events with mousebutton/finger lifted) we can even use normal mouse
input to fake a touch screen.

> > All keys in linux/input.h are supported by the virtio input protocol.
> 
> I'm asking how is this versioned: assume that linux adds
> a new keycode, existing guests don't expect it.
> Don't we need any negotiation? Is it really always safe to
> ignore keypresses?

Worst case is a non-working key.  I also don't think you'll run into
this in practice.  All fundamental stuff is there.  Stuff which gets
added now is pretty exotic, like this:

=================== cut here ======================

commit 5a1bbf21325bd4f2641f6141fb8c47f6095578dd
Author: Dmitry Torokhov <address@hidden>
Date:   Sat Feb 2 11:53:47 2013 -0800

    Input: add new keycodes for passenger control units
    
    Entertainment systems used in aircraft need additional keycodes
    for their Passenger Control Units, so let's add them.
    
    Signed-off-by: Dmitry Torokhov <address@hidden>

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 5588285..6e4e3c6 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -702,6 +702,11 @@ struct input_keymap_entry {
 #define KEY_CAMERA_LEFT                0x219
 #define KEY_CAMERA_RIGHT       0x21a
 
+#define KEY_ATTENDANT_ON       0x21b
+#define KEY_ATTENDANT_OFF      0x21c
+#define KEY_ATTENDANT_TOGGLE   0x21d   /* Attendant call on or off */
+#define KEY_LIGHTS_TOGGLE      0x21e   /* Reading light on or off */
+
 #define BTN_TRIGGER_HAPPY              0x2c0
 #define BTN_TRIGGER_HAPPY1             0x2c0
 #define BTN_TRIGGER_HAPPY2             0x2c1

=================== cut here ======================

And if you really care about this you'll probably make sure your guests
do know what these key codes are for anyway ;)

> > The current qemu kbd emulation covers all keys qemu knows (see QKeyCode
> > in qapi-schema.json).
> 
> Hmm SDL can give us a bunch of codes like volume up/down
> that you don't seem to include.

Disclaimer: I havn't added QkeyCode, it was there already.

I expect QKeyCode learn more keys in the future.  The input layer
rewrite in the 2.0 devel cycle moved QKeyCode into the focus as it is
used more widely in qemu now.  Until recently it was used only for the
sendkey monitor command.

cheers,
  Gerd