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
