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

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.