On Thu, 30 Apr 2009 13:13:34 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> > Hi! > > I have included docs for the gii extension. Better than nothing? > Indeed. I've been thinking of an extension to get better support for modern mice, not knowing that this already existed. Proves again we need this documentation effort. :) > Index: rfbproto.rst > =================================================================== > --- rfbproto.rst (revision 3794) > +++ rfbproto.rst (working copy) > @@ -777,6 +777,276 @@ > *length* ``U8`` array *text* > =============== ==================== ========== ======================= > > +gii > +--- > + Some notes in the "Input Protocol" chapter might be nice, making people aware early that there are extended versions of the input mechanisms. A section here about the sub-types could possibly also be nice, to quickly get the reader into the design of these messages. Some kind of overview would also help as the messages are not documented in the order that they will actually be sent. And what does "gii" stand for? Perhaps we can have a more descriptive name. > +Version > +~~~~~~~ > + > +The client response to a *gii* Version message from the server is the > +following response: > + > +=============== ==================== ========== ======================= > +No. of bytes Type [Value] Description > +=============== ==================== ========== ======================= > +1 ``U8`` 253 *message-type* > +1 ``SUB_TYPE`` 1 or 129 *endian-and-sub-type* I wonder if we really need to give this a separate type. It is a normal U8 after all, just that the top bit has a special meaning. > +2 ``U16`` 4 *length* > +2 ``U16`` 1 *version* > +=============== ==================== ========== ======================= > + > +*endian-and-sub-type* is a bit-field with the leftmost bit indicating > +big endian if set, and little endian if cleared. The endianess affects > +*all* multibyte fields in the message. The rest of the bits are the > +actual message sub type. > + I take it when you say "all multibyte fields" you are referring to the U16:s and U32:s? I think it we should give them some special type name in that case. It's a bit too easy to glance at the spec, see U16 and assume it's handled like every other U16 in the protocol. It would also mean that you wouldn't have to restate everywhere that these fields need to be handled with concern to endianness. > +===================== =============== ========== ====================== > +No. of bytes Type [Value] Description > +===================== =============== ========== ====================== > +1 ``U8`` 253 *message-type* > +1 ``SUB_TYPE`` 2 or 130 *endian-and-sub-type* > +2 ``U16`` 2 *length* > +31 ``U8`` array *device-name* > +1 ``U8`` 0 *nul-terminator* > +4 ``U32`` *vendor-id* > +4 ``U32`` *producty-id* I'm assuming we have a typo here. ;) > +4 ``EVENT_MASK`` *can-generate* > +4 ``U32`` *num-registers* > +4 ``U32`` *num-valuators* > +4 ``U32`` *num-buttons* > +num-valuators * 116 ``VALUATOR`` *num-valuators* probably to indicate the reference. > +``EVENT_MASK`` is a bit-field indicating which events the device > +can generate. > + > +============= ======================== > +Value Bit name > +============= ======================== > +0x00000020 Key press > +0x00000040 Key release > +0x00000080 Key repeat > +0x00000100 Pointer relative > +0x00000200 Pointer absolute > +0x00000400 Pointer button press > +0x00000800 Pointer button release > +0x00001000 Valuator relative > +0x00002000 Valuator absolute > +============= ======================== I was meaning to put together a README with style guidelines, but haven't had the time. In the conversion I did, I made every table exactly 72 characters wide. This makes them easy to spot and gives a consistent look throughout the document. So if noone objects to that style, I'd like to try to keep everything to it. > +Injecting Events > +~~~~~~~~~~~~~~~~ > + > +=============== ==================== ========== ======================= > +No. of bytes Type [Value] Description > +=============== ==================== ========== ======================= > +1 ``U8`` 253 *message-type* > +1 ``SUB_TYPE`` 0 or 128 *endian-and-sub-type* > +2 ``U16`` *length* > + ``EVENT`` array *device-event* We need a size in the first column. Or use the other style in the document and write something along the lines of "followed by *length* bytes of ``EVENT`` entries". > +``PTR_MOVE_EVENT`` is: > + > +=============== ==================== ========== ======================= > +No. of bytes Type [Value] Description > +=============== ==================== ========== ======================= > +1 ``U8`` 24 *event-size* > +1 ``U8`` 8 or 9 *event-type* > +2 ``U16`` *padding* > +4 ``U32`` *device-origin* > +4 ``S32`` *x* > +4 ``S32`` *y* > +4 ``S32`` *z* > +4 ``S32`` *wheel* > +=============== ==================== ========== ======================= > + What about mice with multiple wheels? Having a static number of axis was a bit short sighted. I guess a PTR_MOVE_EVENT_EX could be added in the future though. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
