On Thu, Jan 27, 2011 at 02:11:35PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> Next revision the pvmouse protocol.  It is quite different now, I've
> decided to move to a model with one message per updated value,
> simliar to the linux input layer.  There isn't a "mouse move"
> message any more.  A mouse move event will be three messages now:
> one to update X, one to update Y and a third sync message to mark
> the end of the message block.  That should be *alot* easier to
> extend in the future.
> 
> Header file is attached.  Comments are welcome.
> 
Comments inline (one at the very end).

> thanks,
>   Gerd

> #ifndef __QEMU_PVMOUSE__
> #define __QEMU_PVMOUSE__ 1
> 
> /*
>  * qemu patavirtual mouse/tablet interface
>  *
>  * quick overview
>  * ==============
>  *
>  * device initialization
>  * ---------------------
>  *
>  *  (1) host sends INIT with supported feature bits
>  *  (2) guests sends ACK to ack the features it is
>  *      able to handle (and willing to use).
>  *  (3) host sends a INFO message for each button and
>  *      each axis supported.  More INFO messages might
>  *      follow for features added to the protocol later
>  *      on if enabled by the INIT+ACK handshake.
>  *      A SYNC message marks the end of the device
>  *      information messages.
>  *
>  * input event reporting
>  * ---------------------
>  *
>  *  host sends one or more BTN_DOWN, BTN_UP and AXIS messages,
>  *  followed by a SYNC.  A button press would be just BTN_DOWN+SYNC.
>  *  A mouse move would be two AXIS messages (one for x, one for y)
>  *  followed by SYNC.
>  *
>  * multitouch events
>  * -----------------
>  *
>  *  Each reported touch point starts with a POINT message, followed by
>  *  multiple AXIS messages (at least x+y, most likely also pressure).
>  *  The whole group is followed by SYNC.  A report for two fingers
>  *  would look like this:
>  *
>  *   POINT
>  *     AXIS x=23
>  *     AXIS y=42
>  *     AXIS pressure=3
>  *   POINT
>  *     AXIS x=78
>  *     AXIS y=56
>  *     AXIS pressure=4
>  *   SYNC
>  *
>  *  In case the device supports ID tracking the POINT message will
>  *  carry the ID.  Updates need only be sent for points which did
>  *  change.  IDs are added by using them the first time.  IDs are
>  *  invalidated when the finger is lifted (aka pressure=0).
>  *
>  *  In case the device doesn't support ID tracking each report must
>  *  include all current touch points (in unspecified order).
>  *
>  */
> 
> #include <inttypes.h>
> 
> /*
>  * our virtio-serial channel name(s)
>  */
> #define QEMU_PVMOUSE_FORMAT "org.qemu.pvmouse.%d"
> 
> enum qemu_pvmouse_msg_type {
>     /* feature flag negotiation */
>     QEMU_PVMOUSE_MSG_INIT,
>     QEMU_PVMOUSE_MSG_ACK,
>     /* device information */
>     QEMU_PVMOUSE_MSG_AXIS_INFO,
>     QEMU_PVMOUSE_MSG_BUTTON_INFO,
>     /* device events */
>     QEMU_PVMOUSE_MSG_BTN_DOWN,
>     QEMU_PVMOUSE_MSG_BTN_UP,
>     QEMU_PVMOUSE_MSG_AXIS,
>     /* message grouping */
>     QEMU_PVMOUSE_MSG_POINT,
>     QEMU_PVMOUSE_MSG_SYNC,
> };
> 
> typedef enum qemu_pvmouse_features {
>     QEMU_PVMOUSE_FEATURE_MULTITOUCH,
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_INIT, host -> guest
>  * First message.  Sent before any other event.
>  */
> typedef struct qemu_pvmouse_init {
>     uint32_t features;        /* qemu_pvmouse_features */
> } qemu_pvmouse_init;
> 
> /*
>  * QEMU_PVMOUSE_MSG_ACK, guest -> host
>  * Sent after pvmouse_init.  Host will not send
>  * additional messages until this is received.
>  */
> 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"?

> };
> 
> 
> 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.

>     /* relative */
>     QEMU_PVMOUSE_AXIS_REL_X = 257,
>     QEMU_PVMOUSE_AXIS_REL_Y,
>     QEMU_PVMOUSE_AXIS_WHEEL_VERT,
>     QEMU_PVMOUSE_AXIS_WHEEL_HORIZ,
> };
> 
> enum qemu_pvmouse_axis_flags {
>     QEMU_PVMOUSE_AXIS_PEN,
>     QEMU_PVMOUSE_AXIS_TOUCH,
>     QEMU_PVMOUSE_AXIS_MULTITOUCH,
>     QEMU_PVMOUSE_AXIS_POINT_ID,
> };
> #define QEMU_PVMOUSE_AXIS_MASK_PEN         (1 << QEMU_PVMOUSE_AXIS_PEN)
> #define QEMU_PVMOUSE_AXIS_MASK_TOUCH       (1 << QEMU_PVMOUSE_AXIS_TOUCH)
> #define QEMU_PVMOUSE_AXIS_MASK_MULTITOUCH  (1 << QEMU_PVMOUSE_AXIS_MULTITOUCH)
> #define QEMU_PVMOUSE_AXIS_MASK_POINT_ID    (1 << QEMU_PVMOUSE_AXIS_ID)
> 
> /*
>  * QEMU_PVMOUSE_MSG_AXIS_INFO, host -> guest
>  * Send axis informations.
>  */
> typedef struct qemu_pvmouse_axis_info {
>     uint32_t axis_id;
>     uint32_t type;
>     uint32_t flags;
>     int32_t  min;
>     int32_t  max;
>     char     label[];
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_AXIS, host -> guest
>  * Send mouse/pen/finger/wheel move events.
>  */
> typedef struct qemu_pvmouse_axis_event {
>     uint32_t axis_id;
>     int32_t  value;
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_BUTTON_INFO, host -> guest
>  * Send button informations.
>  */
> typedef struct qemu_pvmouse_button_info {
>     uint32_t button_id;
>     char     label[];
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_BTN_{DOWN,UP}, host -> guest
>  * Send button press+release events.
>  */
> typedef struct qemu_pvmouse_btn_event {
>     uint32_t button_id;
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_POINT, host -> guest
>  * marks the start of a point group for multitouch devices.
>  */
> typedef struct qemu_pvmouse_point {
>     uint32_t id;
> };
> 
> /*
>  * QEMU_PVMOUSE_MSG_SYNC, host -> guest
>  * Marks the end of a message group which belongs together
>  * and carries the time stamp for all those events.
>  *
>  * The timestamp is specified in nanoseconds.  Timebase is undefined.
>  * This is supposed to be used to figure how much time passed between
>  * two events, to decide whenever two mouse clicks should be
>  * interpreted as double click or not and simliar stuff.
>  */
> typedef struct qemu_pvmouse_sync {
>     uint64_t timestamp;
> };
> 
> 
> typedef struct qemu_pvmouse_header {
>     uint32_t size;            /* whole message size */
>     uint32_t type;            /* qemu_pvmouse_type */
> } qemu_pvmouse_header;
> 
> typedef union qemu_pvmouse_payload {
>     qemu_pvmouse_init     init;
>     qemu_pvmouse_ack      ack;
>     /* ... */
> };
> 
> typedef struct qemu_pvmouse_message {
>     qemu_pvmouse_header  hdr;
>     qemu_pvmouse_payload data;
> } qemu_pvmouse_message;
> 
> #endif /* __QEMU_PVMOUSE__ */

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?


> _______________________________________________
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


Reply via email to