Paolo Bonzini <pbonz...@redhat.com> writes:
> Il 13/06/2013 09:01, Anthony Liguori ha scritto:
>> Paolo Bonzini <pbonz...@redhat.com> writes:
>>
>>> Il 13/06/2013 06:19, Andreas Färber ha scritto:
>>>> Am 31.05.2013 14:31, schrieb Amos Kong:
>>>>> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
>>>>> index cdb18e6..fdb9912 100644
>>>>> --- a/hw/input/ps2.c
>>>>> +++ b/hw/input/ps2.c
>>>>> @@ -615,7 +615,17 @@ static bool ps2_keyboard_repeatstate_needed(void
>>>>> *opaque)
>>>>> {
>>>>> PS2KbdState *s = opaque;
>>>>>
>>>>> - return s->repeat_period || s->repeat_delay;
>>>>> + return s->repeat_period || s->repeat_delay || s->repeat_key ||
>>>>> s->repeat_timer;
>>>>> +}
>>>>> +
>>>>> +static int ps2_kbd_repeatstate_load(QEMUFile *f, void *opaque, int
>>>>> version_id)
>>>>> +{
>>>>> + PS2KbdState *s = opaque;
>>>>> + qemu_get_timer(f, s->repeat_timer);
>>>>> + qemu_mod_timer(s->repeat_timer, qemu_get_clock_ns(vm_clock) +
>>>>> + muldiv64(get_ticks_per_sec(), s->repeat_period,
>>>>> 1000));
>>>>> +
>>>>> + return 0;
>>>>> }
>>>>>
>>>>> 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.
>
> 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
