Re: Re: [PATCH] Input: vmmouse - add macros to enable vmmouse relative mode

From: zongmin zhou
Date: Thu Apr 27 2023 - 22:34:47 EST


On Thu, 2023-04-20 at 09:49 +0800, 周宗敏 wrote:
> > Dear zack:
> >  
> > As far as I know, I think in the current design for vmmouse device,
> > the mouse mode can only choose one,can't request both two mode.
> >  
> > The flowchart for vmmouse device between host and guest roughly as
> > > follows:
picture link: https://imgs.wiki/imgs/2023/04/28/1898b0428ecb366a.png

> > QEMU VMMouse emulation code defined variables of 's->absolute'
> > to identify the mouse mode requested by the guest driver.
> > Based on the value of 's->absolute',qemu will add different >
> > spice-input VD-Interface,
> > spice-server will notify client to use the correct mouse mode,
> > and then spice client will update mouse motion/position based on
> > the > mouse mode.
> >  
> > About the VMMOUSE_RELATIVE_PACKET events,I guess that designer may
> > > want use it
> > to distinguish relative from absolute of the process events.But >
> > doesn't mark them as such
> > on QEMU's vmmouse device code.In fact, the status corresponds to
> > the > following buttons value on QEMU:
link: https://imgs.wiki/imgs/2023/04/28/2c6a92c33e2537dd.png
> >
> > From the screenshot we can know it didn't mark the mouse mode
> > status > on original design,
> > only set the actual button state. So I think have to mark it here >
> > according to the value of 's->absolute'.
> >  
Dear zack:

I guess the last mail sent to you may has been lost 
as I don't see it in lore.kernel.org.Just resending it.

If you have any questions, please let me know.
Thanks.
> > Best Regards.
> >
> > ----
> >  
> >
> >
> >
> > 主 题:Re: [PATCH] Input: vmmouse - add macros to enable vmmouse >
> > relative mode
> > 日 期:2023-04-14 23:32
> > 发件人:zackr@xxxxxxxxxx
> > 收件人:dmitry.torokhov@xxxxxxxxx;Pv-
> > drivers;zhouzongmin@xxxxxxxxxx;Linux> -graphics-maintainer;
> >
> > On Fri, 2023-04-14 at 16:58 +0800, zongmin zhou wrote:
> > > > On Fri, 2023-04-14 at 01:22 +0000, Zack Rusin wrote:
> > > > > > On Thu, 2023-04-13 at 16:56 +0800, Zongmin Zhou wrote:
> > > > > > > > Add macros to enable request relative mode.
> > > > > > > >
> > > > > > > > Change the REL_Y value passed by input_report_rel
> > > > > > > > function,
> > > > > > > > to match the direction of mouse movement.
> > > > > >
> > > > > > Thanks for the patch, but in its current form it's a nack.
> > > > > > First > > > of
> > > > > > all we don't
> > > > > > want any defines in the driver code that affect
> > > > > > compilation, it's
> > > > > > never going to be
> > > > > > tested or compiled in. Either a kconfig or a module
> > > > > > parameter > > > would
> > > > > > be acceptable
> > > > > > but that's only if you can actually explain what it is that
> > > > > > > > > you're
> > > > > > fixing. The
> > > > > > current single line description just mentions what the
> > > > > > effect it > > > has
> > > > > > (not completely
> > > > > > correctly either because for merged packets absolute will
> > > > > > still > > > be
> > > > > > x=x, y=y, but
> > > > > > relative will be x += dx, y -= dy) but not why it's done,
> > > > > > what > > > it's
> > > > > > fixing and how
> > > > > > to reproduce.
> > > > > >
> > > > > > z
> > > > > >
> > > > Dear zack:
> > > >
> > > > Firstly,thanks for your reply.
> > > >
> > > > The reason I want to add macros to request different vmmouse
> > > > modes(relative or absolute) is that the vmmouse drivers
> > > > currently > > only
> > > > supports request absolute mode.But in some case we want request
> > > > relative mode so that Pointer acceleration feature can be
> > > > used.(as > > I
> > > > know,libinput module only support Pointer acceleration feature
> > > > in
> > > > relative mode.)
> > > > So I think we can provide two vmmouse modes to facilitate the
> > > > use > > of
> > > > different needs.
> > > > If need,I can change it to a kconfig or a module parameter.
> > > >
> > > > The reasons of fix for REL_Y value,are as follows:
> > > > When I request relative vmmouse mode,and let mouse move up,the
> > > > > > mouse
> > > > pointer moved down instead.
> > > > Similarly, when I move the mouse down, the mouse pointer moved
> > > > up.
> > > > it obviously with a wrong motion direction in y.
> > > >
> > > > Actually,I understand that the value of y here is the end > >
> > > > calculation
> > > > result of relative coordinate movement,the real calculation is
> > > > in
> > > > motion_event() of spice-gtk and legacy_mouse_event() of qemu.
> > > >
> > > > Test scenario:
> > > > 1) start virtual machine with qemu command "vmport=on",also
> > > > with > > spice
> > > > protocal.
> > > > 2) modify guest vmmouse drivers to request relative mode.
> > > > 3) move the mouse,will observe the pointer freezed,it's because
> > > > > > driver
> > > > not match the condition 'status &
> > > > VMMOUSE_RELATIVE_PACKET',can't > > find
> > > > correct input device.need merge this patch in qemu:
> > > > https://lore.kernel.org/all/20230413081526.2229916-1-zhouzongmin@xxxxxxxxxx/
> > > > 4) after merge the patch in qemu,we can observe the issue of
> > > > wrong
> > > > motion direction in y.
> >
> > Sounds like you have a bug in the monitor code to me. The mouse
> > might > request
> > relative mode, but that doesn't mean that it's going to be
> > switched, > it's a hint. On
> > enable we definitely want to request the default absolute mode.
> >
> > Ultimately it's the delivery mechanism (i.e. whether the delivered
> > > event is
> > VMMOUSE_RELATIVE_PACKET or not) that defines what an event is. This
> > > sounds to me
> > like the monitor delivers VMMOUSE_RELATIVE_PACKET events but
> > doesn't > mark them as
> > such. You can confirm by putting some debugging output in the >
> > vmmouse_report_events.
> >
> > z
> >