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 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 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 th
On Fri, Jan 21, 2011 at 05:14:11PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >>The spice-specific issue here is that spice supports multihead, i.e.
> >>you have two displays in the guest and two windows on the host, and
> >>mouse positions are reported as (x,y,window). Question is how to
> >>handle
Hi,
The spice-specific issue here is that spice supports multihead, i.e.
you have two displays in the guest and two windows on the host, and
mouse positions are reported as (x,y,window). Question is how to
handle this best ...
how much do you know about the window configuration?
if you know
On Thu, Jan 20, 2011 at 12:54:07PM +0100, Gerd Hoffmann wrote:
> On 01/20/11 07:25, Peter Hutterer wrote:
> >Hi guys,
> >
> >I apologize for replying this way, I wasn't on the spice-list, jrb pointed
> >out this thread to me. For those who don't know me, I'm the input maintainer
> >for X.Org. I als
On 01/20/11 07:25, Peter Hutterer wrote:
Hi guys,
I apologize for replying this way, I wasn't on the spice-list, jrb pointed
out this thread to me. For those who don't know me, I'm the input maintainer
for X.Org. I also know very little about spice, so please take the comments
below accordingly.
Hi guys,
I apologize for replying this way, I wasn't on the spice-list, jrb pointed
out this thread to me. For those who don't know me, I'm the input maintainer
for X.Org. I also know very little about spice, so please take the comments
below accordingly. Comments regarding a few things that showe
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
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 th
On 14 January 2011 09:37, Anthony Liguori 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
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
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
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 th
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/
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
>
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
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 fi
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,
> So it'd end up being (x,y,pressure) N times (I think 16 is fine for
> the foreseeable future).
It's highly speculative, but Microsoft just released Surface 2, and it is able
to handle up to 40 different pressure points... It is aimed at people in
reunion meeting around a table and manipulation
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 sen
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 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 go
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 re
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 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 */
uin
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
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
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 resoluti
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 */
>>>ui
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 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; /* qem
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
*/
#include
/* our virtio-serial channel */
#
34 matches
Mail list logo
