$Id: NOTES,v 1.11 2002/08/05 06:12:37 d Exp $ Notes on the CERDISP ("Remote Display Control") protocol 'Cerdisp' is Microsoft's WinCE Remote Display 'powertoy' utility. It consists of a screen-grabbing client that runs on the handheld, and a screen-displaying server (or host) that runs on the workstation. This document covers the TCP/IP based protocol observed between the client (cerdisp.exe v2.03) and the server (cerhost.exe v2.03). (So, yeah, this program should really have been called Xcerhost!) Client->Server -------------- When run, the client asks the user for a hostname to connect to (defaulting to "PPP_PEER", but it accepts IP addresses too). It then connects to TCP/IP port 987 of the given server host and immediately sends a 0x130 byte preamble: 0x0000 DWORD preamble length to follow (0x130) 0x0004 DWORD magic number? ("jmm\005" 0x6a6d6d05) 0x0008 DWORD display width in pixels 0x000c DWORD display height in pixels 0x0010 DWORD colour depth 0x0014 DWORD ? (3) 0x0018 DWORD ? (0) 0x001c CHR*128 platform type 0x009c CHR*128 device type 0x011c CHR*16 device name 0x012c DWORD ? (0) All integer data is little endian, and character data is ASCII. DWORD indicates a 32-bit integer, WORD is 16-bit, and CHR is 8-bit. Palette ------- The Windows documentation mentions that 2, 4, 8 and 16 bit displays are supported. If the colour depth is 4, a palette header is sent 0x0000 DWORD ? (always 1?) 0x0004 DWORD length of pallete data following, in bytes For a colour depth of 4, 16 palette entries then follow. Each entry is a colour in the following format: 0x0000 CHR red 0x0001 CHR green 0x0002 CHR blue 0x0003 CHR ? (Please note that the data could well be in blue/green/red or some other order. So far only gray palettes have been observed, making it difficult to guess the order!) For a colour depth of 16, no palette header or entries are sent. Frame ----- Immediately after the optional palette, the client sends the first screen frame. The frame begins with a 0x18 byte frame header: 0x0000 DWORD ? (0) 0x0004 DWORD total size of following frame data in WORDs 0x0008 DWORD ? (0, possibly x offset?) 0x000c DWORD ? (0, possibly y offset?) 0x0010 DWORD width in pixels 0x0014 DWORD height in pixels which is followed by frame data consisting of WORD pairs, compressed using run-length encoding (RLE). Each pair describes a run length count, and a pixel (or group of pixels). 0x0000 WORD run length 0x0002 WORD pixel information The run length is how many times that pixel (or group of pixels) is to be repeatedly plotted, starting at the top left, and moving from left to right and wrapping at the right edge. For a colour depth of 16, the 16-bit pixel information word carries the red, green and blue intensities of a single pixel, in the following (big endian) bit format: bits 11-15 blue bit 10 ? bits 5-9 green bits 0-4 red For depth 4 (paletted colour), the 16-bit pixel information word describes the colours of four separate pixels in the following (big endian) format: bits 12-15 p1 bits 8-11 p0 bits 4-7 p3 bits 0-3 p2 The values of p0 through p3 are indicies into the pallete for the four pixels, and are to be plotted in the order p0,p1,p2,p3. RLE data continues until all pixels in the current display frame have been sent. After the frame content has been sent, and perhaps after a short delay, the next frame's header is sent and the process repeats. When the client quits, it simply closes the TCP/IP connection without warning. Server->Client -------------- The server is generally quiet, only sending input directives to the client. There is no preamble or establishment protocol. For pointer events, the server sends 6-byte input directives that looks like this: 0x0000 WORD state change (0x0002=down 0x0004=up 0x0000=none) 0x0002 WORD x coord 0x0004 WORD y coord When the pointer is being dragged, these directives are continuously sent to update the new pointer position, but the state change field is set to zero. Keystroke events look like this: 0x0000 WORD state (0x0100 = key down, 0x0101 = key up) 0x0002 WORD keycode Modifier keys are treated as physical keys, i.e. the client keeps track of modifier state by itself. Generally, keys are sent in their unmodified state. For example, a shifted 'A' is sent as the series of 4 events: . The caps lock key is a toggle; i.e. will put the client into a capslock state; to leave the capslock state, the same pair of events have to be sent again. (Numlock is similar.) Keycodes are not ASCII, though some keys coincide with ascii (the uppercase letters, numbers, space, tab, esc and return.) The following keyboard indicates what keycodes are associated with which key: ESC 1 2 3 4 5 6 7 8 9 0 - = Backsp x1b x31 x32 x33 x34 x35 x36 x37 x38 x39 x30 xbd xbb 0x08 TAB q w e r t y u i o p [ ] x09 x51 x57 x45 ... ... ... ... ... ... ... xdb xdd CapsLock a s d f g h j k l ; ' Return x14 x41 ... ... ... ... ... ... ... ... xba xde x0d Shift z x c v b n m , . / x10 x5a ... ... ... ... ... ... xbc xbe xbf Control ` \ Space Dn Up Lt Rt x11 xc0 xdc x20 x28 x26 x25 x27 Pause (sleep): 0xdf To end a session, the server simply closes the TCP/IP connection. David Leonard, 2002. Public domain.