[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]