Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat

[Amos Kong <akong@redhat.com>]

On Thu, Jun 13, 2013 at 01:28:14PM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> > Il 13/06/2013 09:01, Anthony Liguori ha scritto:
> >> Paolo Bonzini <pbonzini@redhat.com> writes:

> >>>>>  static bool ps2_keyboard_ledstate_needed(void *opaque)
> >>>>> @@ -638,9 +648,12 @@ static const VMStateDescription
> >>>>> vmstate_ps2_keyboard_repeatstate = {
> >>>>>      .version_id = 3,
> >>>>>      .minimum_version_id = 2,
> >>>>>      .minimum_version_id_old = 2,
> >>>>> +    .load_state_old = ps2_kbd_repeatstate_load,
> >>>>>      .fields      = (VMStateField[]) {
> >>>>>          VMSTATE_INT32(repeat_period, PS2KbdState),
> >>>>>          VMSTATE_INT32(repeat_delay, PS2KbdState),
> >>>>> +        VMSTATE_INT32(repeat_key, PS2KbdState),
> >>>>> +        VMSTATE_TIMER(repeat_timer, PS2KbdState),
> >>>>
> >>>> You can't just add fields here, they'd need to be specific to a new
> >>>> version 4. Requested was to make it a subsection instead.
> >>>
> >>> This is already a subsection, and this patch is just a proposal to be
> >>> squashed in this series (which adds the subsection).  But I think Amos
> >>> is right and only the period/delay need to be migrated.  Otherwise,
> >>> you'll get an endless stream of repeats on the destination.
>
> >> Not with seamless migration and spice.

Auto-repeat is just a feature of keyboard hardware.
ps2 keyboard will repeatedly emit events to guest.

But for guest side, it could not repeatedly input/display
one key if it only receive a press event and wait a long time.

I used a timer to emulate hardware to repeatedly emit press
events to guest.


(1) IF we migrate the timer: (problem occured :(
when we execute migrate/re-connect, and qemu doesn't receive
the release event from host system. Auto-repeat will
continua, even qemu doesn't get events from host system.

(1) IF we DON'T migrate the repeat_timer: (everything is ok :)
when we execute re-connection or migration, qemu can continually
receive press events from host system if the key is pressed in the
new vnc/spice side. The key _can_be auto-repeatedly inputed.


SO we should not migrate the repeat_timer.

The auto-repeated input after migration/re-connection should be
decided by if the key is pressed in the new spice/vnc client.


Amos.

> > Which BTW is broken right now in Fedora, though I didn't investigate
> > who's the culprit. :)
> >
> >> Even with a non-seamless VNC reconnect, if it happens behind the scenes
> >> the release would still be sent.
>
> > Where is the code for that?  Are SDL/GTK/whatnot covered as well?
> 
> What I mean by non-seamless migration is a management tool transparently
> reconnecting after live migration.
>
> I assume virt-manager does this but we certainly have management
> products that do this.
> 
> The (remote) user see a blib in the session but if they had a key held
> down, then the release will certainly still be sent to the other end.
> 
> Even with GTK/SDL, if a key was depressed it will continue to be
> depressed which will cause odd behavior with accelerators.  At least
> with key repeat happening it's more obvious to the user that a key is
> stuck.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Paolo