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