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: Gerd Hoffmann
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 09:06:11 +0100

> 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.

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.

cheers,
  Gerd





reply via email to

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