qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]