[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Break cross migration from qemu-1.5 to qemu-2.1.
From: |
Gonglei |
Subject: |
Re: [Qemu-devel] [RFC] Break cross migration from qemu-1.5 to qemu-2.1. because of input/hid rewriting |
Date: |
Fri, 21 Nov 2014 16:44:34 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 |
On 2014/11/21 16:06, Gerd Hoffmann wrote:
>> What about this patch:
>>
>> diff --git a/hw/input/hid.c b/hw/input/hid.c
>> index 148c003..56e0637 100644
>> --- a/hw/input/hid.c
>> +++ b/hw/input/hid.c
>> @@ -116,7 +116,7 @@ static void hid_pointer_event(DeviceState *dev,
>> QemuConsole *src,
>> HIDState *hs = (HIDState *)dev;
>> HIDPointerEvent *e;
>>
>> - assert(hs->n < QUEUE_LENGTH);
>> + assert(hs->n <= QUEUE_LENGTH);
>> e = &hs->ptr.queue[(hs->head + hs->n) & QUEUE_MASK];
>>
>> switch (evt->kind) {
>
> No. There is a reason this assert is in there. This needs to be
> handled in a post_load function, to bring the queue into a state 2.1 can
> deal with.
>
OK.
> Easiest would be to just flush the queue in case n == 16, or leave in
> there a single event with final pointer location and button state.
>
> I think you can also try to combine events (like it is done for
> event_compression = true). qemu 1.5 was less aggressive in doing that
> (only did it when the queue was full), so chances are high that you'll
> find events in the queue with identical button state where you can
> either just drop all but the last first (tablet mode) or add up the
> motions (mouse mode). Not sure it is worth the trouble though.
>
Sorry, I'm not familiar with the realization of input/hid module. Could you
please post a patch for this issue? Thanks a lot!
Best regards,
-Gonglei