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
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
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
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
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
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
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
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
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
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
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,
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
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,
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.
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
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.
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)
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
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
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
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 */
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; /*
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;
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
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; /*
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 */
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 */
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
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
29 matches
Mail list logo
