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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list