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@xxxxxxxxxx> 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 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
