Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Jul 22, 2010 at 10:28:39AM -0300, Luiz Capitulino wrote:
> On Wed, 21 Jul 2010 20:06:56 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> > On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > > Another related issue is that, this probably should an async handler. But
> > > as we don't have the proper infrastructure yet, I'm ok with having this in
> > > its current form.
> > > 
> > > > +- "hold_time": duration in milliseconds to hold the keys down (json-int, optional, default=100)
> > 
> > Having 'hold-time' which applies to the full list of keys is limiting
> > the flexibility of apps. eg, it means you can only do
> > 
> >    down ctrl
> >    down alt
> >    down f1
> >    wait 100ms
> >    up ctrl
> >    up alt
> >    up f1
> > 
> > Again I can see why the impl works this way currently, because it is
> > clearly a nicer option for humans. For a machine protocol though it
> > seems sub-optimal. What if app needed more flexibility over ordering
> > of press+release events eg to release in a different order
> > 
> >    down ctrl
> >    down alt
> >    down f1
> >    wait 100ms
> >    up f1
> >    up ctrl
> >    up alt
> > 
> > Should we just follow VNC and explicitly have a up/down flag in
> > the protocol & let press & release events be sent separately.
> > 
> >   { "execute": "sendkey", "arguments":  { "keycode": 0x31, "down": true } }
> > 
> > We could allow multiple keycodes in one message
> > 
> >   { "execute": "sendkey", "arguments":  { "keycodes": [ 0x31, 0x32 ], "down": true } }
> > 
> > but its not really adding critical functionality that can't be got by
> > sending a sequence of sendkey commands in a row.
> 
> Hm, looks good to me, but then the hold time would be the time period
> between the down/up commands. This won't be reliable in case the client
> wants to exactly wait 100ms, as we can have network latency, for example.
> 
> Isn't this a problem? I believe VNC doesn't have this feature, right?

Correct, VNC just sends each individual press / release event as a separate
message, so you can have network delay effects there too.

If we needed to support precise delays safe from network delay for some
simulation needs, then you'd probably need a more complex structure
where you can provide a whole sequence of operations. And why stop at
keys, including mouse movement & buttons to.

   { "execute": "sendinput", "arguments":  { 
       "sequence" : [
          { "event": "keypress", "keycode": 0x31 },
          { "event": "keypress", "keycode": 0x75 },
          { "event": "wait", "delay": 100 },
          { "event": "mousepress", "button": 1 },
          { "event": "mousemove", "xdelta": 1, "ydelta": 1 },
          { "event": "keyrelease", "keycode": 0x31 },
          { "event": "wait", "delay": 100 },
          { "event": "keyrelease", "keycode": 0x75 },
          { "event": "mousepos", "x": 102, "y": 102 },
       ] 
   } }

This is getting kind of advanced now. Whether we need this vs the simpler
sendkey, mouse_move, etc command comes down to whether we need ability to
set precise delays between events.  We could stick with the individual
simple commands & add a advanced one alter  

Daniel
--
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|