qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/5] msmouse: Handle mouse reset


From: Arwed Meyer
Subject: Re: [PATCH v2 1/5] msmouse: Handle mouse reset
Date: Mon, 12 Sep 2022 19:54:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

Am 12.09.22 um 19:45 schrieb Arwed Meyer:
Am 11.09.22 um 20:27 schrieb Peter Maydell:
On Sun, 11 Sept 2022 at 18:14, Arwed Meyer <arwed.meyer@gmx.de> wrote:

Am 08.09.22 um 23:11 schrieb Peter Maydell:
On Thu, 8 Sept 2022 at 18:43, Arwed Meyer <arwed.meyer@gmx.de> wrote:

Detect mouse reset via RTS or DTR line:
Don't send or process anything while in reset.
When coming out of reset, send ID sequence first thing.
This allows msmouse to be detected by common mouse drivers.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/77
Signed-off-by: Arwed Meyer <arwed.meyer@gmx.de>

How does this work across migration? There doesn't seem
to be anything that handles migration of the existing
state inside the MouseChardev either, though...

can you please explain in more detail what you don't understand and what
you mean by "migration"?

Migration is when the state of the whole VM is copied from
one host to another, or, equivalently, when it is saved to
the disk image with 'savevm' to be restarted later. For this
to work all the guest-changeable state in the whole VM (all
device registers, internal state, etc) has to be saved so
it can be reloaded on the destination. My question is basically
how this new state in mouse->tiocm, and more generally how
the existing other state fields in that struct, are saved
and loaded during the migration process. I know how this
works for device models, but I'm not sure how chardevs
figure into it. (Perhaps the answer is "this shouldn't be
a chardev at all" ???)

thanks
-- PMM

Hi,

thanks for adding some context. Good question.
Unfortunately I don't know the device and migration code much, so I
can't really say anything about this. I guess(!) it should be enough to
save/load contents of struct MouseChardev. No idea if and how this can
be done though.
Also since saving/loading device state wasn't supported in the msmouse
code to begin with, for me this is a new feature and out of scope for
this patch set.
The result of this missing feature might be that mouse buttons are
detected as not pressed and mouse movement data is lost after migration.


Regards

... more specific regarding to mouse->tiocm:
Since it is initialized to 0, the device is put to reset after restoring
state/migrating and won't react. You'd probably have to reload the
client's mouse driver to get the mouse up and running again.


Regards



reply via email to

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