diff options
author | RajithaY <rajithax.yerrumsetty@intel.com> | 2017-04-25 03:31:15 -0700 |
---|---|---|
committer | Rajitha Yerrumchetty <rajithax.yerrumsetty@intel.com> | 2017-05-22 06:48:08 +0000 |
commit | bb756eebdac6fd24e8919e2c43f7d2c8c4091f59 (patch) | |
tree | ca11e03542edf2d8f631efeca5e1626d211107e3 /qemu/ui/vnc-enc-tight.h | |
parent | a14b48d18a9ed03ec191cf16b162206998a895ce (diff) |
Adding qemu as a submodule of KVMFORNFV
This Patch includes the changes to add qemu as a submodule to
kvmfornfv repo and make use of the updated latest qemu for the
execution of all testcase
Change-Id: I1280af507a857675c7f81d30c95255635667bdd7
Signed-off-by:RajithaY<rajithax.yerrumsetty@intel.com>
Diffstat (limited to 'qemu/ui/vnc-enc-tight.h')
-rw-r--r-- | qemu/ui/vnc-enc-tight.h | 183 |
1 files changed, 0 insertions, 183 deletions
diff --git a/qemu/ui/vnc-enc-tight.h b/qemu/ui/vnc-enc-tight.h deleted file mode 100644 index a3add788e..000000000 --- a/qemu/ui/vnc-enc-tight.h +++ /dev/null @@ -1,183 +0,0 @@ -/* - * QEMU VNC display driver: tight encoding - * - * From libvncserver/rfb/rfbproto.h - * Copyright (C) 2005 Rohit Kumar, Johannes E. Schindelin - * Copyright (C) 2000-2002 Constantin Kaplinsky. All Rights Reserved. - * Copyright (C) 2000 Tridia Corporation. All Rights Reserved. - * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved. - * - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to deal - * in the Software without restriction, including without limitation the rights - * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell - * copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, - * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN - * THE SOFTWARE. - */ - -#ifndef VNC_ENCODING_TIGHT_H -#define VNC_ENCODING_TIGHT_H - -/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Tight Encoding. - * - *-- The first byte of each Tight-encoded rectangle is a "compression control - * byte". Its format is as follows (bit 0 is the least significant one): - * - * bit 0: if 1, then compression stream 0 should be reset; - * bit 1: if 1, then compression stream 1 should be reset; - * bit 2: if 1, then compression stream 2 should be reset; - * bit 3: if 1, then compression stream 3 should be reset; - * bits 7-4: if 1000 (0x08), then the compression type is "fill", - * if 1001 (0x09), then the compression type is "jpeg", - * if 1010 (0x0A), then the compression type is "png", - * if 0xxx, then the compression type is "basic", - * values greater than 1010 are not valid. - * - * If the compression type is "basic", then bits 6..4 of the - * compression control byte (those xxx in 0xxx) specify the following: - * - * bits 5-4: decimal representation is the index of a particular zlib - * stream which should be used for decompressing the data; - * bit 6: if 1, then a "filter id" byte is following this byte. - * - *-- The data that follows after the compression control byte described - * above depends on the compression type ("fill", "jpeg", "png" or "basic"). - * - *-- If the compression type is "fill", then the only pixel value follows, in - * client pixel format (see NOTE 1). This value applies to all pixels of the - * rectangle. - * - *-- If the compression type is "jpeg" or "png", the following data stream - * looks like this: - * - * 1..3 bytes: data size (N) in compact representation; - * N bytes: JPEG or PNG image. - * - * Data size is compactly represented in one, two or three bytes, according - * to the following scheme: - * - * 0xxxxxxx (for values 0..127) - * 1xxxxxxx 0yyyyyyy (for values 128..16383) - * 1xxxxxxx 1yyyyyyy zzzzzzzz (for values 16384..4194303) - * - * Here each character denotes one bit, xxxxxxx are the least significant 7 - * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the - * most significant 8 bits (bits 14-21). For example, decimal value 10000 - * should be represented as two bytes: binary 10010000 01001110, or - * hexadecimal 90 4E. - * - *-- If the compression type is "basic" and bit 6 of the compression control - * byte was set to 1, then the next (second) byte specifies "filter id" which - * tells the decoder what filter type was used by the encoder to pre-process - * pixel data before the compression. The "filter id" byte can be one of the - * following: - * - * 0: no filter ("copy" filter); - * 1: "palette" filter; - * 2: "gradient" filter. - * - *-- If bit 6 of the compression control byte is set to 0 (no "filter id" - * byte), or if the filter id is 0, then raw pixel values in the client - * format (see NOTE 1) will be compressed. See below details on the - * compression. - * - *-- The "gradient" filter pre-processes pixel data with a simple algorithm - * which converts each color component to a difference between a "predicted" - * intensity and the actual intensity. Such a technique does not affect - * uncompressed data size, but helps to compress photo-like images better. - * Pseudo-code for converting intensities to differences is the following: - * - * P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1]; - * if (P[i,j] < 0) then P[i,j] := 0; - * if (P[i,j] > MAX) then P[i,j] := MAX; - * D[i,j] := V[i,j] - P[i,j]; - * - * Here V[i,j] is the intensity of a color component for a pixel at - * coordinates (i,j). MAX is the maximum value of intensity for a color - * component. - * - *-- The "palette" filter converts true-color pixel data to indexed colors - * and a palette which can consist of 2..256 colors. If the number of colors - * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to - * encode one pixel. 1-bit encoding is performed such way that the most - * significant bits correspond to the leftmost pixels, and each raw of pixels - * is aligned to the byte boundary. When "palette" filter is used, the - * palette is sent before the pixel data. The palette begins with an unsigned - * byte which value is the number of colors in the palette minus 1 (i.e. 1 - * means 2 colors, 255 means 256 colors in the palette). Then follows the - * palette itself which consist of pixel values in client pixel format (see - * NOTE 1). - * - *-- The pixel data is compressed using the zlib library. But if the data - * size after applying the filter but before the compression is less then 12, - * then the data is sent as is, uncompressed. Four separate zlib streams - * (0..3) can be used and the decoder should read the actual stream id from - * the compression control byte (see NOTE 2). - * - * If the compression is not used, then the pixel data is sent as is, - * otherwise the data stream looks like this: - * - * 1..3 bytes: data size (N) in compact representation; - * N bytes: zlib-compressed data. - * - * Data size is compactly represented in one, two or three bytes, just like - * in the "jpeg" compression method (see above). - * - *-- NOTE 1. If the color depth is 24, and all three color components are - * 8-bit wide, then one pixel in Tight encoding is always represented by - * three bytes, where the first byte is red component, the second byte is - * green component, and the third byte is blue component of the pixel color - * value. This applies to colors in palettes as well. - * - *-- NOTE 2. The decoder must reset compression streams' states before - * decoding the rectangle, if some of bits 0,1,2,3 in the compression control - * byte are set to 1. Note that the decoder must reset zlib streams even if - * the compression type is "fill", "jpeg" or "png". - * - *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only - * when bits-per-pixel value is either 16 or 32, not 8. - * - *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048 - * pixels. If a rectangle is wider, it must be split into several rectangles - * and each one should be encoded separately. - * - */ - -#define VNC_TIGHT_EXPLICIT_FILTER 0x04 -#define VNC_TIGHT_FILL 0x08 -#define VNC_TIGHT_JPEG 0x09 -#define VNC_TIGHT_PNG 0x0A -#define VNC_TIGHT_MAX_SUBENCODING 0x0A - -/* Filters to improve compression efficiency */ -#define VNC_TIGHT_FILTER_COPY 0x00 -#define VNC_TIGHT_FILTER_PALETTE 0x01 -#define VNC_TIGHT_FILTER_GRADIENT 0x02 - -/* Note: The following constant should not be changed. */ -#define VNC_TIGHT_MIN_TO_COMPRESS 12 - -/* The parameters below may be adjusted. */ -#define VNC_TIGHT_MIN_SPLIT_RECT_SIZE 4096 -#define VNC_TIGHT_MIN_SOLID_SUBRECT_SIZE 2048 -#define VNC_TIGHT_MAX_SPLIT_TILE_SIZE 16 - -#define VNC_TIGHT_JPEG_MIN_RECT_SIZE 4096 -#define VNC_TIGHT_DETECT_SUBROW_WIDTH 7 -#define VNC_TIGHT_DETECT_MIN_WIDTH 8 -#define VNC_TIGHT_DETECT_MIN_HEIGHT 8 - -#endif /* VNC_ENCODING_TIGHT_H */ |