Den 2009-05-11 13:35 skrev Pierre Ossman: > Why is there both a numerical code, and a string pair used to identify > the extension? It seems a bit redundant.
Once upon a time I asked about related things on the tight list: http://www.nabble.com/Tight-protocol-extension---clarification-needed-td15063207.html >> + >> +The following *encoding* capabilities are registered: >> + >> +=========== ========= ============= =================================== >> +Code Vendor Signature Description >> +=========== ========= ============= =================================== >> +0 ``STDV`` ``RAW_____`` `Raw Encoding`_ >> +1 ``STDV`` ``COPYRECT`` `CopyRect Encoding`_ >> +2 ``STDV`` ``RRE_____`` `RRE Encoding`_ >> +4 ``STDV`` ``CORRE___`` CoRRE Encoding >> +5 ``STDV`` ``HEXTILE_`` `Hextile Encoding`_ >> +6 ``TRDV`` ``ZLIB____`` ZLib Encoding >> +7 ``TGHT`` ``TIGHT___`` Tight Encoding >> +8 ``TRDV`` ``ZLIBHEX_`` ZLibHex Encoding >> +-32 ``TGHT`` ``JPEGQLVL`` JPEG Quality Level 0 >> +-223 ``TGHT`` ``NEWFBSIZ`` New FB Size >> +-224 ``TGHT`` ``LASTRECT`` Last Rect >> +-232 ``TGHT`` ``POINTPOS`` Pointer Position >> +-239 ``TGHT`` ``RCHCURSR`` Rich Cursor >> +-240 ``TGHT`` ``X11CURSR`` X Cursor >> +-256 ``TGHT`` ``COMPRLVL`` Compression Level 0 >> +-305 ``GGI_`` ``GII_____`` `gii (General Input Interface) >> + Pseudo-encoding`_ >> +=========== ========= ============= =================================== > > Nit-picking, but code was defined as U32, not S32. :) Yes, code is defined as unsigned by tight, but I feel that it should be filled with the encoding value, not its unsigned hexadecimal representation as is used by the tight team. I'd much rather have the same list here as in the SetEncodings message and live with the S32/U32 mismatch... Here's a new version or the patch, with politics moved to the README file, links added for encodings documented since last time and the previously missing extension to the SecurityResult message added. BTW, you may compare my spec with this one: http://vnc-tight.svn.sf.net/viewvc/vnc-tight/trunk/doc/rfbtight.odt Beware, there are errors in that document. Some are obvious (the document doesn't make sense) but one major fault is that it lacks the 2 padding bytes between the number of encodings and the list of server message types in the "Capabilities negotiation" chapter. Cheers, Peter ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
