From: Zack Rusin <zackr@vmware.com>
To: "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
Pv-drivers <Pv-drivers@vmware.com>,
"zhouzongmin@kylinos.cn" <zhouzongmin@kylinos.cn>,
Linux-graphics-maintainer <Linux-graphics-maintainer@vmware.com>
Cc: "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH] Input: vmmouse - add macros to enable vmmouse relative mode
Date: Thu, 27 Apr 2023 02:35:59 +0000 [thread overview]
Message-ID: <3a4f27ad2122fe0457dc2a41a3b1b24ac556d26c.camel@vmware.com> (raw)
In-Reply-To: <rk3ip31xbz-rk4smwgz5s@nsmail7.0.0--kylin--1>
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:
> 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:
>
> 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'.
Hi,
we had a quick chat about this internally and I don't think we can make this work as
is. The core issue is that this driver is for VMware's mouse, if qemu emulation of
that device diverges from that then we can't make it work, i.e. if the device that
qemu emulates doesn't match the behaviour of vmmouse then it's not a vmmouse.
I think there are three possible solutions here:
1) Fix qemu so that it properly flags relative vs absolute events
2) Implement some capabilities mechanism so that we can shoehorn what effectively is
a different device that happens to have the same pci id into this driver (not ideal)
3) Fork the driver, make any changes you wish and just remember to change the device
detection for the qemu mouse so it differs from vmmouse. The driver is fairly simple
and is not too big, if fixing qemu is not an option then you effectively have a
different device and then just properly treat it as such. From your initial patch
where you wanted to have the relative flag as a define, it seems that your kernel is
custom anyway (because otherwise you wouldn't be able to set that define) so this
should be trivially doable on your config. And long term you can submit the new
driver to the kernel (as long as you can make sure the mouse detection code doesn't
detect the actual vmmouse of course to conflict with this driver).
z
next parent reply other threads:[~2023-04-27 2:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <rk3ip31xbz-rk4smwgz5s@nsmail7.0.0--kylin--1>
2023-04-27 2:35 ` Zack Rusin [this message]
2023-04-28 2:34 ` Re: [PATCH] Input: vmmouse - add macros to enable vmmouse relative mode zongmin zhou
2023-04-28 3:35 ` Zack Rusin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a4f27ad2122fe0457dc2a41a3b1b24ac556d26c.camel@vmware.com \
--to=zackr@vmware.com \
--cc=Linux-graphics-maintainer@vmware.com \
--cc=Pv-drivers@vmware.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zhouzongmin@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).