From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSZ6U-0006X0-00 for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:46:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSZ6T-0006WX-6Q for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:46:53 -0500 Received: from [199.232.76.173] (port=58155 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSZ6S-0006WR-WD for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:46:53 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:56331) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSZ6S-0004NU-LL for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:46:52 -0500 Received: by qyk13 with SMTP id 13so12468028qyk.10 for ; Thu, 29 Jan 2009 07:46:52 -0800 (PST) Message-ID: <4981CF4D.1040202@codemonkey.ws> Date: Thu, 29 Jan 2009 09:46:21 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1233228298-4844-1-git-send-email-agraf@suse.de> <1233228298-4844-2-git-send-email-agraf@suse.de> <4981C9B2.20709@codemonkey.ws> <4981CB4A.9070303@suse.de> In-Reply-To: <4981CB4A.9070303@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/7] Split VNC defines to vnc.h Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org Alexander Graf wrote: > Anthony Liguori wrote: > >> Alexander Graf wrote: >> >>> The VNC protocol contains quite some constants, some of which are >>> currently hardcoded in the vnc.c code. This is not exactly pretty. >>> >>> Let's move all those constants out to vnc.h, so they are clearly >>> separated. While at it, I also included other defines that will be >>> used later in this patch series. >>> >>> >> A much needed change. >> >> >>> diff --git a/vnc.h b/vnc.h >>> new file mode 100644 >>> index 0000000..ae69bc3 >>> --- /dev/null >>> +++ b/vnc.h >>> @@ -0,0 +1,130 @@ >>> +#ifndef __VNCTIGHT_H >>> +#define __VNCTIGHT_H >>> + >>> +/***************************************************************************** >>> >>> + * >>> + * Authentication modes >>> + * >>> + >>> *****************************************************************************/ >>> >>> + >>> +enum { >>> + VNC_AUTH_INVALID = 0, >>> + VNC_AUTH_NONE = 1, >>> + VNC_AUTH_VNC = 2, >>> + VNC_AUTH_RA2 = 5, >>> + VNC_AUTH_RA2NE = 6, >>> + VNC_AUTH_TIGHT = 16, >>> + VNC_AUTH_ULTRA = 17, >>> + VNC_AUTH_TLS = 18, >>> + VNC_AUTH_VENCRYPT = 19 >>> +}; >>> + >>> +#define VNC_AUTH_NONE_SIG "NOAUTH__" >>> +#define VNC_AUTH_VNC_SIG "VNCAUTH_" >>> >>> >> These AUTH sigs are not part of the standard as far as I'm aware of >> it. This is the VNC_AUTH_TIGHT stuff? I'd rather not do that. >> > > Right. That is the follow-up from AUTH_TIGHT. Tight uses signatures in > general as addition to normal codes. The same thing applies to the > encoding signatures. These are required for the "Hey client, I know > these encodings" packet. > > >>> + >>> +#define VNC_ENCODING_RAW 0x00000000 >>> +#define VNC_ENCODING_COPYRECT 0x00000001 >>> +#define VNC_ENCODING_RRE 0x00000002 >>> +#define VNC_ENCODING_CORRE 0x00000004 >>> +#define VNC_ENCODING_HEXTILE 0x00000005 >>> +#define VNC_ENCODING_ZLIB 0x00000006 >>> +#define VNC_ENCODING_TIGHT 0x00000007 >>> +#define VNC_ENCODING_ZLIBHEX 0x00000008 >>> >>> >> This was never standardized. >> > > From rfbproto.h of current tightvnc: > > #define rfbEncodingRaw 0 > #define rfbEncodingCopyRect 1 > #define rfbEncodingRRE 2 > #define rfbEncodingCoRRE 4 > #define rfbEncodingHextile 5 > #define rfbEncodingZlib 6 > #define rfbEncodingTight 7 > #define rfbEncodingZlibHex 8 > #define rfbEncodingZRLE 16 > [...] > #define rfbEncodingXCursor 0xFFFFFF10 > #define rfbEncodingRichCursor 0xFFFFFF11 > #define rfbEncodingPointerPos 0xFFFFFF18 > > #define rfbEncodingLastRect 0xFFFFFF20 > #define rfbEncodingNewFBSize 0xFFFFFF21 > > Where else should I look for defines? I'd rather have them here and if > anything collide than not in any header files. > http://www.realvnc.com/docs/rfbproto.pdf is where the protocol is defined. Early in VNC's life, when TightVNC first fork()'d from RealVNC, there was no formal protocol definition. This led to some incompatible implementations so if you want to maintain compatibility with the largest number of clients, it's best to stick to what's defined by the standard. Regards, Anthony Liguori