[Spice-devel] [RFC PATCH spice-common v2 02/20] A version 2 of the MousePosition message

[Gerd Hoffmann]

On Mon, Aug 27, 2018 at 12:13:47PM -0400, Frediano Ziglio wrote:
> > 
> > Hi,
> > 
> > > +typedef struct SpiceMsgcMousePositionV2 {
> > > +    uint32_t x;
> > > +    uint32_t y;
> > > +    uint32_t buttons_state;
> > > +    uint32_t channel_id;
> > > +    uint32_t monitor_id;
> > > +} SpiceMsgcMousePositionV2;
> > 
> > When touching the mouse messages anyway I'd suggest to design it more
> > like the linux input layer events (or qemu input subsystem, which was
> > inspiried by the linux input layer too).
> > 
> > cheers,
> >   Gerd
> > 
> 
> Designing a multi-OS protocol on a specific OS seems to me a design
> mistake. I would prefer to design it looking at existent hardware
> or designing looking at multiple OSes.

Well, the linux input layer (specifically the evdev protocol, see
/usr/include/linux/input.h) is roughly two decades old and managed to
handle all sorts of hardware without major protocol changes.  So it
can't be that bad ...

The fundamental idea is to have one message per value.  Each message is
has type, code and value.  So for a mouse button press you would have
four messages:

   type                 code          value

   relative move        x axis        23
   relative move        y axis        -42
   key event            left button   down
   sync

The "sync" indicates the end of the message group.  This can be extended
easily.  You can add an axis for the scroll wheel without changing the
wire protocol, it'll be just an additional message.  Old software
versions can simply skip messages they doesn't understand.

You can also send the display that way:

   type                 code          value

   display              channel id    0
   display              monitor id    2
   absolute position    x axis        582
   [ ... ]

cheers,
  Gerd