Re: [Qemu-devel] paravirtual mouse/tablet, v5
On Mi, 2011-02-02 at 14:48 +1000, Peter Hutterer wrote: ^^ FYI: It's been a while ... sorry, late again. conference last week. On Thu, Jan 27, 2011 at 02:11:35PM +0100, Gerd Hoffmann wrote: 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. I like this approach, it's a lot more flexible and quite close to what the linux kernel already does. Having said that, I'm thinking why not do exactly what the linux kernel does? ... but there is working code now, doing exactly that. There is a new virtio input device, which basically sends evdev events over virtio. specs: http://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input linux kernel: http://www.kraxel.org/cgit/linux/log/?h=virtio-input qemu (also containing some unrelated qemu input stuff): http://www.kraxel.org/cgit/qemu/log/?h=rebase/input-wip Of course it's not limited to a mouse, there is a virtio keyboard too, and we can pass through any host input device to the guest. cheers, Gerd [ leaving full quote below for those which might look at it for historical interest ] * the kernel has a stable API that has a number of users and is well understood, plus * it allows for code re-use on the consumer side * you'd need to do protocol conversion anyway. having the same API means at least one platform (i.e. linux) can skip the conversion. * MT is being worked on by a number of people and two protocols that cater for current hardware (with and without HW tracking features). trying to duplicate this means we'll likely re-do the same mistakes. fwiw, this protocol is already quite similar MSG_SYNC is SYN_REPORT MSG_POINT is SYN_MT_REPORT AXIS x is the same as EV_ABS + ABS_X there may be some optimization for networks of course if you want to change the message format but at least the principle seems sound enough. Header file is attached. Comments are welcome. 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). what's the effect of a guest not able to handle certain features? The host filters them? * (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. fwiw, kernel doesn't have BTN_DOWN events but rather BTN_FOO 0 or 1 events (for released and pressed, respectively). Same for keys, which also allows keys to have a value of 2 for autorepeat. it provides more symmetry as well because currently you have AXIS axis code axis value BTN_DOWN button code so axis and button_down are asymmetrical in format. alternatively, you could use AXIS axis code axis value BTN button code button value thus making the message format identical. * * 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). how about devices that support hovering, where the pressure is 0 but the touchpoint is still clearly in proximity and active? * 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
Re: [Qemu-devel] paravirtual mouse/tablet, v5
On 01/27/2011 07:11 AM, 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. I can't comment on the multitouch bits but I like the new interface. Regards, Anthony Liguori thanks, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet, v5
On 01/27/11 15:27, Anthony Liguori wrote: On 01/27/2011 07:11 AM, 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. I can't comment on the multitouch bits but I like the new interface. BTW: Is there any plan for guest code already? Should it stay within the qemu source tree, in a guest/ directory maybe? pvmouse daemon would live there, also the upcoming guest agent bits. Before finally committing to some protocol I'd like to have at least a simple proof-of-concept which is able to handle all the mouse events the current qemu mouse infrastructure is able to handle. Oh, and we'll have to define endianness of course so it keeps working if host and guest have a different byteorder. I'd suggest to pick network byte order aka bigendian. cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet, v5
On 01/27/2011 08:53 AM, Gerd Hoffmann wrote: On 01/27/11 15:27, Anthony Liguori wrote: On 01/27/2011 07:11 AM, 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. I can't comment on the multitouch bits but I like the new interface. BTW: Is there any plan for guest code already? Should it stay within the qemu source tree, in a guest/ directory maybe? pvmouse daemon would live there, also the upcoming guest agent bits. I think it should live in the QEMU tree or at least on qemu.org. We want these agents to be ubiquitous. Before finally committing to some protocol I'd like to have at least a simple proof-of-concept which is able to handle all the mouse events the current qemu mouse infrastructure is able to handle. Oh, and we'll have to define endianness of course so it keeps working if host and guest have a different byteorder. I'd suggest to pick network byte order aka bigendian. Makes sense to me. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On 17.01.2011, at 08:48, Gerd Hoffmann wrote: There are three cases: (1) no pressure supported (i.e. your mouse moving around in the vnc window and qemu reporting this as tablet coordinates). (2) just pen/finger present/not present supported. pressure jumps between 0 and max (and we can make max == 1 in that case). Phew - that's one of the bits where touchpads and tablets behave differently IIUC. For touchpads, pressing means movement happens. For tablets, pressing means an actual press, as if you would press your pencil on a sheet of paper. So for tablets, pressure==1 basically means click. I wouldn't make a difference from the virtual hardware perspective. If something touches the pad/tablet surface we'll report the position where it happened (and the pressure if supported). Whenever this is interpreted as click or not is up to the guest. There is a major difference. Touching means on Touchpad: movement of cursor Tablet: pressing down a pen This difference needs to be reflected somehow. Maybe in the future there might even be devices that combine both. Imagine a tablet device that has a capacitive touchpad, but also accepts pen input, so you can draw on it. This would be separate events. Pressing down a pen would be interpreted completely differently from touching something on the device. Alex
Re: [Qemu-devel] paravirtual mouse/tablet
Hi, I was just talking to Chase Douglas here at the ubuntu sprint about this, and he pointed me at https://launchpad.net/rinput which is a program which can forward remote events including multitouch over the network (including forwarding from both Linux and MacOS X clients). Maybe that would be worth looking at since it's a working implementation of forwarding multitouch events between systems? Looks like they are basically using the linux input layer protocol. cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
There are three cases: (1) no pressure supported (i.e. your mouse moving around in the vnc window and qemu reporting this as tablet coordinates). (2) just pen/finger present/not present supported. pressure jumps between 0 and max (and we can make max == 1 in that case). Phew - that's one of the bits where touchpads and tablets behave differently IIUC. For touchpads, pressing means movement happens. For tablets, pressing means an actual press, as if you would press your pencil on a sheet of paper. So for tablets, pressure==1 basically means click. I wouldn't make a difference from the virtual hardware perspective. If something touches the pad/tablet surface we'll report the position where it happened (and the pressure if supported). Whenever this is interpreted as click or not is up to the guest. Now the thing is that multitouch gestures might take non-click pressure into account for their calculations. So we need pressure for movements on touchpads, but with tablets, we only need pressure when clicks happen. For everyone else, clicks would just be a button press. -EPARSE. What is non-click pressure ? cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On Fri, Jan 14, 2011 at 04:13:29PM +0100, Gerd Hoffmann wrote: Hi, So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). I'd tend to extend MOVE to (x,y,pressure,index) and send N events with the same timestamp. Needs to send only as many events as it finds fingers on the touchpad, i.e. usually just one or two, even if the protocol can easily handle alot more than 16 ;) Doesn't that lose the coincidence? I expect mostly presses happen sequentially (milliseconds apart maybe, but still), so probably not an issue at all. For a simple tablet pressure and index would just be 0. The details of what exactly that means should be figured out by the guest driver. Agree. I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. Buttons events are for buttons. Real ones, which apple lost ;) Of course a tap on the trackpad is usually interpreted as mouse click. But that is the job of the guest OS, our virtual hardware doesn't care. But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh. There must be an interface to get (more or less) the raw touchpad data, for apps which want implement their own multitouch gestures? cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
Hi, * multitouch capabilities would be good to design in a mouse protocol for 2011, so having say 16 x/y pairs would be better Point. What do we need here? Finger $n down, finger $n up, finger $n moved to $x,$y? Does it make sense to just add this to the move+buttonup/down structs? Or should it better be separate? * on mac os at least scrolling is not done by pressing virtual buttons, but by having a separate scroll interface that knows about velocity and such - maybe worth adding that to the protocol from the beginning too. Is that actually done by the hardware? I'd expect macos processes the multitouch events, then provides this (finger $n moves this fast into that direction) as high-level interface, so this isn't something we have to care about at virtual hardware level. cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On 14.01.2011, at 12:27, Gerd Hoffmann wrote: Hi, * multitouch capabilities would be good to design in a mouse protocol for 2011, so having say 16 x/y pairs would be better Point. What do we need here? Finger $n down, finger $n up, finger $n moved to $x,$y? Does it make sense to just add this to the move+buttonup/down structs? Or should it better be separate? I guess a mere tuple of (x,y,down) N times should be enough for the protocol, no? This would even be useful for single-point tablets which usually also have a proximity detector. Thinking about this a bit more - there are proximity sensors in tablets :). So they know how hard you pressed. If we want to be able to forward that to the guest from a real world tablet, we need a pressure field. So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). The details of what exactly that means should be figured out by the guest driver. If the guest is multitouch capable, it'd forward those events to the respective system. If it's tablet compatible, take the first entry and if it only supports plain mice, just make it (x,y) when pressure 0. * on mac os at least scrolling is not done by pressing virtual buttons, but by having a separate scroll interface that knows about velocity and such - maybe worth adding that to the protocol from the beginning too. Is that actually done by the hardware? I'd expect macos processes the multitouch events, then provides this (finger $n moves this fast into that direction) as high-level interface, so this isn't something we have to care about at virtual hardware level. I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. I'd frankly assume they do that in software with their own multitouch detection code though, so it should be fine to have the buttons as legacy interface as long as there is multitouch to implement the scrolling. But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh. Alex
Re: [Qemu-devel] paravirtual mouse/tablet
Hi, So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). I'd tend to extend MOVE to (x,y,pressure,index) and send N events with the same timestamp. Needs to send only as many events as it finds fingers on the touchpad, i.e. usually just one or two, even if the protocol can easily handle alot more than 16 ;) For a simple tablet pressure and index would just be 0. The details of what exactly that means should be figured out by the guest driver. Agree. I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. Buttons events are for buttons. Real ones, which apple lost ;) Of course a tap on the trackpad is usually interpreted as mouse click. But that is the job of the guest OS, our virtual hardware doesn't care. But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh. There must be an interface to get (more or less) the raw touchpad data, for apps which want implement their own multitouch gestures? cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On 14.01.2011, at 16:13, Gerd Hoffmann wrote: Hi, So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). I'd tend to extend MOVE to (x,y,pressure,index) and send N events with the same timestamp. Needs to send only as many events as it finds fingers on the touchpad, i.e. usually just one or two, even if the protocol can easily handle alot more than 16 ;) For a simple tablet pressure and index would just be 0. For a simple tablet pressure would be MAX and index would be 0. But yes, I like the idea :). The details of what exactly that means should be figured out by the guest driver. Agree. I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. Buttons events are for buttons. Real ones, which apple lost ;) Of course a tap on the trackpad is usually interpreted as mouse click. But that is the job of the guest OS, our virtual hardware doesn't care. With an interface the way you mention it below (self-implemented gesture support), this shouldn't be an issue. A tap should just get forwarded to the guest as a tap and then the guest can configure what a tap means - which is what users want. But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh. There must be an interface to get (more or less) the raw touchpad data, for apps which want implement their own multitouch gestures? I'm not sure there is, but that seems like the only viable solution. This way the guest can define its own multitouch gestures that the host doesn't even have to know about (think of osx guests on linux hosts for example). Alex
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/14/2011 08:36 AM, Alexander Graf wrote: On 14.01.2011, at 12:27, Gerd Hoffmann wrote: Hi, * multitouch capabilities would be good to design in a mouse protocol for 2011, so having say 16 x/y pairs would be better Point. What do we need here? Finger $n down, finger $n up, finger $n moved to $x,$y? Does it make sense to just add this to the move+buttonup/down structs? Or should it better be separate? I guess a mere tuple of (x,y,down) N times should be enough for the protocol, no? Surely, evdev has an interface to support this already. Let's just do what it does instead of inventing something that none of us can validate actually works. Or better yet, delay implementing it until someone actually knows how to support it. Regards, Anthony Liguori This would even be useful for single-point tablets which usually also have a proximity detector. Thinking about this a bit more - there are proximity sensors in tablets :). So they know how hard you pressed. If we want to be able to forward that to the guest from a real world tablet, we need a pressure field. So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). The details of what exactly that means should be figured out by the guest driver. If the guest is multitouch capable, it'd forward those events to the respective system. If it's tablet compatible, take the first entry and if it only supports plain mice, just make it (x,y) when pressure 0. * on mac os at least scrolling is not done by pressing virtual buttons, but by having a separate scroll interface that knows about velocity and such - maybe worth adding that to the protocol from the beginning too. Is that actually done by the hardware? I'd expect macos processes the multitouch events, then provides this (finger $n moves this fast into that direction) as high-level interface, so this isn't something we have to care about at virtual hardware level. I'm not familiar with the hardware interface, but in order to support that the background interface must be a lot more complex than a simple button press. I'd frankly assume they do that in software with their own multitouch detection code though, so it should be fine to have the buttons as legacy interface as long as there is multitouch to implement the scrolling. But then again - how would we forward fine-grained scrolling to the guest if we only know that it's scrolling, but not what the actual presses on the touchpad looked like? Ugh. Alex
Re: [Qemu-devel] paravirtual mouse/tablet
On 14.01.2011, at 16:28, Alexander Graf wrote: On 14.01.2011, at 16:13, Gerd Hoffmann wrote: Hi, So it'd end up being (x,y,pressure) N times (I think 16 is fine for the foreseeable future). I'd tend to extend MOVE to (x,y,pressure,index) and send N events with the same timestamp. Needs to send only as many events as it finds fingers on the touchpad, i.e. usually just one or two, even if the protocol can easily handle alot more than 16 ;) For a simple tablet pressure and index would just be 0. For a simple tablet pressure would be MAX and index would be 0. But yes, I like the idea :). 0 for non-presses of course :). Sorry Alex
Re: [Qemu-devel] paravirtual mouse/tablet
Hi, For a simple tablet pressure and index would just be 0. For a simple tablet pressure would be MAX and index would be 0. But yes, I like the idea :). 0 for non-presses of course :). Sorry Right ;) There are three cases: (1) no pressure supported (i.e. your mouse moving around in the vnc window and qemu reporting this as tablet coordinates). (2) just pen/finger present/not present supported. pressure jumps between 0 and max (and we can make max == 1 in that case). (3) real pressure measurement. Will send out v3 shortly. cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
Hi, I guess a mere tuple of (x,y,down) N times should be enough for the protocol, no? Surely, evdev has an interface to support this already. Let's just do what it does instead of inventing something that none of us can validate actually works. http://www.mjmwired.net/kernel/Documentation/input/multi-touch-protocol.txt Looks like the linux input layer does effectively the same: send series of events for multitouch. A sync event to mark the end of the batch is obviously a pretty good idea I'm going to steal. Some devices seem to be able to attach IDs to the touchpoints. Then you don't have to send the whole set each time but can limit yourself to the ones which did actually change. We should support that too. Or better yet, delay implementing it until someone actually knows how to support it. I think we can get sane support into the protocol right from start, and that is much better than adding something afterwards. Just look at the linux input layer document -- some of the loops they have to hop though are there just because multitouch is a extension which came later. cheers, Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On 14.01.2011, at 17:31, Gerd Hoffmann wrote: Hi, For a simple tablet pressure and index would just be 0. For a simple tablet pressure would be MAX and index would be 0. But yes, I like the idea :). 0 for non-presses of course :). Sorry Right ;) There are three cases: (1) no pressure supported (i.e. your mouse moving around in the vnc window and qemu reporting this as tablet coordinates). (2) just pen/finger present/not present supported. pressure jumps between 0 and max (and we can make max == 1 in that case). Phew - that's one of the bits where touchpads and tablets behave differently IIUC. For touchpads, pressing means movement happens. For tablets, pressing means an actual press, as if you would press your pencil on a sheet of paper. So for tablets, pressure==1 basically means click. Now the thing is that multitouch gestures might take non-click pressure into account for their calculations. So we need pressure for movements on touchpads, but with tablets, we only need pressure when clicks happen. For everyone else, clicks would just be a button press. Tricky. Alex
Re: [Qemu-devel] paravirtual mouse/tablet
On 14 January 2011 09:37, Anthony Liguori anth...@codemonkey.ws wrote: [multitouch] Surely, evdev has an interface to support this already. Let's just do what it does instead of inventing something that none of us can validate actually works. Or better yet, delay implementing it until someone actually knows how to support it. I was just talking to Chase Douglas here at the ubuntu sprint about this, and he pointed me at https://launchpad.net/rinput which is a program which can forward remote events including multitouch over the network (including forwarding from both Linux and MacOS X clients). Maybe that would be worth looking at since it's a working implementation of forwarding multitouch events between systems? -- PMM
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 04:19 AM, Gerd Hoffmann wrote:
Hi,
Just throwing a quick writeup into the ring to kickstart the design
discussion ;)
cheers,
Gerd
#ifndef __QEMU_PVTABLET__
#define __QEMU_PVTABLET__ 1
/*
* qemu patavirtual tablet interface
*/
#includeinttypes.h
/* our virtio-serial channel */
#define QEMU_PVTABLET_NAME org.qemu.pvtablet.0
enum qemu_pvtablet_buttons {
QEMU_PVTABLET_BTN_LEFT,
QEMU_PVTABLET_BTN_RIGHT,
QEMU_PVTABLET_BTN_MIDDLE,
/*
* we can handle up to 32 buttons although
* not every has a individual name;)
*/
};
/* send button down+up events */
typedef struct qemu_pvtablet_button {
uint32_t button;
uint32_t mask;
} qemu_pvtablet_button;
/* send pointer move events */
typedef struct qemu_pvtablet_position {
uint32_t pos_x; /* range: 0 - 0x */
uint32_t pos_y; /* range: 0 - 0x */
} qemu_pvtablet_position;
Let's add feature negotiation and not hardcode the resolution.
typedef enum qemu_pvtablet_features {
/* None yet */
};
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
} qemu_pvtablet_init;
/* guest-host, sent after pvtablet_init. host will not send additional
messages until this is received */
typedef struct qemu_pvtablet_ack {
uint32_t features; /* qemu_pvtable_features */
};
enum qemu_pvtablet_type {
QEMU_PVTABLET_MSG_MOVE, /* qemu_pvtablet_position */
QEMU_PVTABLET_MSG_BTN_DOWN, /* qemu_pvtablet_button */
QEMU_PVTABLET_MSG_BTN_UP, /* qemu_pvtablet_button */
QEMU_PVTABLET_MSG_INIT, /* qemu_pvtable_init */
QEMU_PVTABLE_MSG_ACK, /* qemu_pvtable_ack */
Regards,
Anthony Liguori
};
typedef struct qemu_pvtablet_message {
uint32_t size;/* whole message size */
uint32_t type;/* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
union {
qemu_pvtablet_position position;
qemu_pvtablet_button button;
qemu_pvtablet_display display;
} m;
} qemu_pvtablet_message;
#endif /* __QEMU_PVTABLET__ */
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
uint32_t available_buttons; /* bitmask */
} qemu_pvtablet_init;
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 12:19 PM, Gerd Hoffmann wrote:
Hi,
Just throwing a quick writeup into the ring to kickstart the design
discussion ;)
typedef struct qemu_pvtablet_message {
uint32_t size;/* whole message size */
uint32_t type;/* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
time relative to what base?
can we actually provide it? if the tablet is remote, there may not be a
synchronized time source.
union {
qemu_pvtablet_position position;
qemu_pvtablet_button button;
qemu_pvtablet_display display;
} m;
} qemu_pvtablet_message;
So the message size for a qemu_pvtablet_position would only include the
position member?
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
uint32_t available_buttons; /* bitmask */
Yes, I had intended to do that but left it out.
Should it be a bitmask or just a button count? Buttons really have no
standard meaning so usually a button count is sufficient.
Regards,
Anthony Liguori
} qemu_pvtablet_init;
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 10:18 AM, Avi Kivity wrote:
On 01/13/2011 12:19 PM, Gerd Hoffmann wrote:
Hi,
Just throwing a quick writeup into the ring to kickstart the design
discussion ;)
typedef struct qemu_pvtablet_message {
uint32_t size;/* whole message size */
uint32_t type;/* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
time relative to what base?
can we actually provide it? if the tablet is remote, there may not be
a synchronized time source.
I had the same thought, but if it's just treated as time since the init
message, the guest is capable of working it out (minus drift).
union {
qemu_pvtablet_position position;
qemu_pvtablet_button button;
qemu_pvtablet_display display;
} m;
} qemu_pvtablet_message;
So the message size for a qemu_pvtablet_position would only include
the position member?
I didn't comment on this because I was treating this as a protocol
proposal and not actual code but usually the following is clearer:
struct qemu_pvtablet_hdr {
uint32_t size;
uint32_t type;
uint64_t tv_secs;
uint64_t tv_usecs;
};
struct qemu_pvtablet_position {
struct qemu_pvtablet_hdr hdr;
uint32_t x;
uint32_t y;
};
union qemu_pvtablet_message {
struct qemu_pvtablet_hdr hdr;
struct qemu_pvtablet_position position;
...
};
Regards,
Anthony Liguori
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 05:39 PM, Anthony Liguori wrote:
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
uint32_t available_buttons; /* bitmask */
Yes, I had intended to do that but left it out.
Should it be a bitmask or just a button count? Buttons really have no
standard meaning so usually a button count is sufficient.
3/4 are the mouse wheel, so if you had a mouse with 5 buttons and no
wheel those would be buttons 0/1/2/5/6.
Paolo
Re: [Qemu-devel] paravirtual mouse/tablet
On 13.01.2011, at 17:39, Anthony Liguori wrote:
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
uint32_t available_buttons; /* bitmask */
Yes, I had intended to do that but left it out.
Should it be a bitmask or just a button count? Buttons really have no
standard meaning so usually a button count is sufficient.
Some random thoughts:
* multitouch capabilities would be good to design in a mouse protocol for
2011, so having say 16 x/y pairs would be better
* on mac os at least scrolling is not done by pressing virtual buttons, but
by having a separate scroll interface that knows about velocity and such -
maybe worth adding that to the protocol from the beginning too.
Alex
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/11 17:18, Avi Kivity wrote:
On 01/13/2011 12:19 PM, Gerd Hoffmann wrote:
Hi,
Just throwing a quick writeup into the ring to kickstart the design
discussion ;)
typedef struct qemu_pvtablet_message {
uint32_t size; /* whole message size */
uint32_t type; /* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
time relative to what base?
Guess that needs to be refined ;)
Just something relative (if available) should good enougth. The
intended purpose is being able to figure how much time passed between
two events, so one can figure whenever two mouse clicks should be
considered a double-click or not. Ideally the timestamps from the
original mouse event in the vnc/spice client would be passed all the way
through to the guest. Didn't check the protocols whenever they actually
support that, but I think we should have this in the protocol even if
they don't ...
cheers,
Gerd
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 07:19 PM, Gerd Hoffmann wrote:
On 01/13/11 17:18, Avi Kivity wrote:
On 01/13/2011 12:19 PM, Gerd Hoffmann wrote:
Hi,
Just throwing a quick writeup into the ring to kickstart the design
discussion ;)
typedef struct qemu_pvtablet_message {
uint32_t size; /* whole message size */
uint32_t type; /* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
time relative to what base?
Guess that needs to be refined ;)
Just something relative (if available) should good enougth. The
intended purpose is being able to figure how much time passed between
two events, so one can figure whenever two mouse clicks should be
considered a double-click or not. Ideally the timestamps from the
original mouse event in the vnc/spice client would be passed all the
way through to the guest. Didn't check the protocols whenever they
actually support that, but I think we should have this in the protocol
even if they don't ...
Ok. We should then specify that the base is arbitrary (and get rid of
tv_secs - 2^64 usecs is half a million years, which should be sufficient
time to get a fully threaded qemu.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 11:09 AM, Paolo Bonzini wrote:
On 01/13/2011 05:39 PM, Anthony Liguori wrote:
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host-guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t features; /* qemu_pvtablet_features */
uint32_t available_buttons; /* bitmask */
Yes, I had intended to do that but left it out.
Should it be a bitmask or just a button count? Buttons really have no
standard meaning so usually a button count is sufficient.
3/4 are the mouse wheel, so if you had a mouse with 5 buttons and no
wheel those would be buttons 0/1/2/5/6.
It can still be reported as a 7 button mouse but I don't really mind
either way.
Regards,
Anthony Liguori
Paolo
Re: [Qemu-devel] paravirtual mouse/tablet
On 01/13/2011 11:13 AM, Alexander Graf wrote: Yes, I had intended to do that but left it out. Should it be a bitmask or just a button count? Buttons really have no standard meaning so usually a button count is sufficient. Some random thoughts: * multitouch capabilities would be good to design in a mouse protocol for 2011, so having say 16 x/y pairs would be better * on mac os at least scrolling is not done by pressing virtual buttons, but by having a separate scroll interface that knows about velocity and such - maybe worth adding that to the protocol from the beginning too. Features negotiation takes care of this. Regards, Anthony Liguori Alex
