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

[Luiz Capitulino]

On Thu, 22 Jul 2010 14:45:35 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> 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" <address@hidden> 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  

Yeah, agreed and I think the current design (ie. hold_time) is simpler.