5 a.m.
On 05/26/2011 12:36 AM, Daniel P. Berrange wrote:
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.
OK, it will be removed.
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.
I don't think it is a good idea to add a second API, virDomainSendKey()
is not used directly by human, integer is enough. 2 apis will make the user of
the lib confused.
virsh send-key command is a human interface,
I think it is good if it accepts strings, so I allow KEY_XXX strings.
And this command should wrap all things(convert strings to integers).
If you deny 'xt:keystring', I can remove the patch, but KEY_XXX strings will
still stay.
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.
qemu monitor don't require "ints-->names" conversions, it just needs
very trivial conversions "ints-->0xNN", this conversion will not need
when qmp send-key is implemented.
I don't know other hypervisors, but I think virDomainSendKey() taking
a list of keycode as ints is the best api for all hypervisors.
>
> 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
It is good for me, but I may want to wrap the strings->ints conversions in virsh
instead of in hypervisors.
> .
> .
> .
> 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