From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54611 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiTaK-0000uY-MY for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:16:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiTWG-0007bg-ER for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:12:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiTWG-0007ba-39 for qemu-devel@nongnu.org; Thu, 27 Jan 2011 10:12:20 -0500 Date: Thu, 27 Jan 2011 17:12:12 +0200 From: Alon Levy Message-ID: <20110127151211.GB19334@playa.tlv.redhat.com> References: <4D416F07.6060604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D416F07.6060604@redhat.com> Subject: [Qemu-devel] Re: [Spice-devel] paravirtual mouse/tablet, v5 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Peter Hutterer , "qemu-devel@nongnu.org" , spice-devel 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 > > /* > * 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-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel