qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_butt


From: Brad Hards
Subject: Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command
Date: Sat, 9 Apr 2011 10:21:04 +1000
User-agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.5.1; x86_64; ; )

On Sat, 9 Apr 2011 12:34:21 am Markus Armbruster wrote:
> There's one instance of state: position (if absolute) + buttons for any
> number of mice.  Funny things can happen when you have more than one
> mouse and switch between them.
For the common case (in most OS), each of the mice are mixed together. 
Switching (with the guest powered up) is pretty rare.
 
> Even if there's just one mouse: the state is updated only for monitor
> mouse action.  Funny things can happen when something other than monitor
> commands uses the mouse.
That already happens. If SDL and monitor mouse_move are both used, then "last 
wins".
 
> Shouldn't the state be kept per-mouse?  Monitor could ask for current
> coordinates + button state then.
I thought about keeping the state in input.c code, but that adds more 
complexity and probably won't work properly either (as Anthony pointed out on 
IRC), because the inputs that you've provided to the guest get modified by 
guest code (like mouse acceleration).

> Note buttons are already funny.  The patch just extends the funniness to
> position.  Could be a valid excuse for committing it as is.
Note that the diff doesn't change the behaviour of mouse_move (i.e. position). 
It just "breaks less" for the mouse_button command for the following specific 
situation:
1. You've previously used mouse_move to select the point you want
and
2. You're using an absolute pointing device.

Going back to the original bug report, with current trunk (and the common case 
of an absolute pointing device), mouse_button warps the mouse to the origin if 
you press a button. It seems less surprising to use the last position.

Brad



reply via email to

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