Hi,
typedef struct qemu_pvmouse_ack { uint32_t features; /* qemu_pvtable_features */Why does this comment say "qemu_pvtable_features" and the one above says "qemu_pvmouse_features"?
Not intentional, will fix. Leftover because it is misspelled (t in table*t* missing), so the search+replace didn't catch it.
}; enum qemu_pvmouse_axis_type { /* absolute */ QEMU_PVMOUSE_AXIS_POS_X = 1, QEMU_PVMOUSE_AXIS_POS_Y, QEMU_PVMOUSE_AXIS_PRESSURE,So is the concensus to not treat 3d mice as core protocol? just a AXIS_POS_Z and AXIS_REL_Z I think would be simple to add. Running cad apps in a vm seems possible.
That list isn't meant to be complete, I'll happily take suggestions for axises we should add here. *_Z for a 3d mouse certainly is reasonable.
What's the outcome of the discussion with Peter? wasn't there a suggestion to send information from the host to the guest about monitor configuration, so guest can do inverse to send correct coordinates to host?
Yep. I think that isn't something for the pvmouse but for vdagent though. In the simplest case make VDAgentMonitorsConfig bidirectional, so the guest can send feedback to the spice client and inform how the actual configuration looks like.
cheers, Gerd
