[libvirt] [PATCH 00/13] Add support for send keys to guest
Daniel P. Berrange
berrange at redhat.com
Thu May 26 11:03:33 UTC 2011
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 :|
More information about the libvir-list
mailing list