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