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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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
> 
> 

Well, so instead of tagging messages the protocol is tagging single fields,
something like the difference between a plain text and XML (although there's
no hierarchy in evdev schema). Is possible but this suggestion is more about
base protocol change. I hope we don't continue all this discussion expanding
day by day or in a couple of days we could end up discussing the size of
the bytes; of course this sentence is irritating but keeping focus on a discussion
which is spreading all over is hard, we are moving in a "all or nothing"
discussion.
There was some discussion time ago on protobuf or cap'n proto too.

Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]