On Thu, May 26, 2011 at 06:00:08PM +0800, Lai Jiangshan wrote:
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.
Ok, we can always re-consider at a later date if we find it neccessary todo so. 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 :|