From: Gerd Hoffmann <kraxel@redhat.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Peter Hutterer <peter.hutterer@who-t.net>,
spice-devel <spice-devel@lists.freedesktop.org>
Subject: [Qemu-devel] paravirtual mouse/tablet, v5
Date: Thu, 27 Jan 2011 14:11:35 +0100 [thread overview]
Message-ID: <4D416F07.6060604@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
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.
thanks,
Gerd
[-- Attachment #2: pvmouse.h --]
[-- Type: text/x-chdr, Size: 5392 bytes --]
#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 */
};
enum qemu_pvmouse_axis_type {
/* absolute */
QEMU_PVMOUSE_AXIS_POS_X = 1,
QEMU_PVMOUSE_AXIS_POS_Y,
QEMU_PVMOUSE_AXIS_PRESSURE,
/* 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__ */
next reply other threads:[~2011-01-27 13:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-27 13:11 Gerd Hoffmann [this message]
2011-01-27 14:27 ` [Qemu-devel] paravirtual mouse/tablet, v5 Anthony Liguori
2011-01-27 14:53 ` Gerd Hoffmann
2011-01-27 15:29 ` Anthony Liguori
2011-01-27 15:12 ` [Qemu-devel] Re: [Spice-devel] " Alon Levy
2011-01-27 15:32 ` Gerd Hoffmann
2011-01-27 15:39 ` Alon Levy
2011-02-02 4:48 ` [Qemu-devel] " Peter Hutterer
2014-04-11 13:34 ` [Qemu-devel] " Gerd Hoffmann
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=4D416F07.6060604@redhat.com \
--to=kraxel@redhat.com \
--cc=peter.hutterer@who-t.net \
--cc=qemu-devel@nongnu.org \
--cc=spice-devel@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.