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

Re: [libvirt] [PATCH 00/13] Add support for send keys to guest



On Wed, May 25, 2011 at 05:37:42PM +0800, Lai Jiangshan wrote:
> Add API virDomainSendKey() and virsh send-key command.
> 
> # virsh help send-key
>   NAME
>     send-key - Send keycodes to the guest
> 
>   SYNOPSIS
>     send-key <domain> [--codeset <string>] [--holdtime <number>] <keycode>...
> 
>   DESCRIPTION
>     Send keycodes to the guest, the keycodes must be integers
>     or the qemu-style key strings for the "xt:keystring" codeset
>     or the KEY_* strings listed below for the "linux" codeset.
> 
>     Available codeset:
>         linux          the keycodes specified in 
>                         /usr/include/linux/input.h(default)
>         default        linux codeset will be used
>         driver_default the hypervisor default codeset will be used
>         xt             XT(set1) scancode of standard AT keyboards and PS/2 keyboards
>         atset1         set1 scancode of standard AT keyboards and PS/2 keyboards
>         atset2         set2 scancode of standard AT keyboards and PS/2 keyboards
>         atset3         set3 scancode of standard AT keyboards and PS/2 keyboards
>         xt:keystring   XT scancode, but <keycode>... must be the qemu-style key strings

I was thinking we'd just use the Linux keycode set in the API, but I guess
if the client app already has things in XT codeset, it isn't too nice to
force them to convert to Linux keycodes, only for libvirt to convert them
straight back for QEMU. So I think it was a good idea to add different
codesets.

I don't think that 'driver_default' makes sense though. For that to be
usable, the person invoking the API must somehow know what the driver
default codeset is. If they know that, then they can trivially just
specify that already, so 'driver_default' doesn't seem to add any
benefit.


As for 'xt:keystring', if you think it is worth being able to use
key strings, then perhaps we should have 2 apis. One API that takes
a list of keycodes as ints, and one API that takes a list of keycodes
as strings.

This would avoid the need for every client application to maintain
a mapping table of strings <-> ints. eg, all the mapping tables
would be contained within libvirt.

> 
>     Examples:
> 
>         virsh # send-key <domain> 37 18 21
>         virsh # send-key <domain> --holdtime 1000 0x15 18 0xf
>         virsh # send-key <domain> KEY_LEFTCTRL KEY_LEFTALT KEY_F1
>         virsh # send-key <domain> --codeset xt:keystring alt-sysrq h
> 
>     KEY_XXX strings for the "linux" codeset:

For virsh, perhaps it should default to always using the strings
for the keys, and only use integers if given a special flag. I
think most admins using virsh would just be using strings. The
integer keycodes are mostly useful for apps using the API directly.

eg, perhaps

         virsh # send-key <domain> KEY_LEFTCTRL KEY_LEFTALT KEY_F1
         virsh # send-key <domain> --codeset linux KEY_LEFTCTRL KEY_LEFTALT KEY_F1
         virsh # send-key <domain> --codeset xt alt-sysrq h
         virsh # send-key <domain> --num 37 18 21
         virsh # send-key <domain> --num --holdtime 1000 0x15 18 0xf
         virsh # send-key <domain> --num --codeset linux --holdtime 1000 0x15 18 0xf

> .
> .
> .
>   OPTIONS
>     [--domain] <string>  domain name, id or uuid
>     --codeset <string>   the codeset of keycodes, default:linux
      --num                the keys are specified as integer values,
>     --holdtime <number>  the time (in millsecond) how long the keys will be held
>     <keycode>            the key string (or value if --num is set)


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


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