X Consortium Standard
D. Converse, J. Fulton, C. Kantarjiev, D. Lemke, R. Mor, K. Packard, R. Tice, D. Tonogai
$XConsortium: lbx.html /main/2 1996/12/21 20:26:09 ray $
Copyright (c) 1996 X ConsortiumPermission 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 limita tion the rights to use, copy, modify, merge, publish, distribute, sublicense, and 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, FIT NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the X Consortium shall not be used in advertising or other wise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.
This extension was designed and implemented by Jim Fulton, David Lemke, Keith Packard, and Dale Tonogai, all of Network Computing Devices (NCD). Chris Kent Kantarjiev (Xerox PARC) participated in early design discussions. Ralph Mor (X Consortium) designed and implemented additional sections. Donna Converse (X Consortium) authored the protocol description and encoding from design notes and the imple mentation. Ray Tice (X Consortium) resolved the open issues in the design and specification. Bob Scheifler (X Consortium) helped out in many areas.
The extension name is "LBX".
Much of LBX is implemented as an extension. The compression and reencoding changes can be isolated to the transport and dispatch portions of the server, while short-circuiting requires minor changes to the server's colormap and property code.
LBX employs several different compression and short-circuiting methods. Use of these methods is negotia ble, and in some cases, the algorithm used by a given method is negotiable as well. LBX also provides for negotiation of extensions to LBX.
0. Client requests
1. Read by LBX and potential byte-swapping
2. Request-specific compression
3. Potential byte swapping
4. Multiplexing of client request streams
5. Delta replacement
6. Stream compression
Transport
6. Stream decompression
5. Delta substitution
4. Demultiplexing of client request streams
3. Potential byte swapping
2. Reencoding
1. Request processing
The reverse process occurs with X server replies, events, and errors.
Tag usage is negotiated as a boolean in the LbxStartProxy message. The proxy controls how many tags are stored in the proxy. The server may wish to observe the proxy's InvalidateTag behavior to limit how many tags are cached at any one time. Tagged data is not shared across types of tags, but the number space used for the tag ids is. The tag ids are generated by the server.
The X server keeps track of what tags are known to the proxy. The proxy can invalidate a tag if no tag bear ing replies of that type are pending. The proxy sends an LbxInvalidateTag message to release the tagged data. The proxy must not invalidate connection tags unless instructed to do so by the server.
If the server wishes to discard tagged data, it must either have received an LbxInvalidateTag request from the proxy or send an LbxInvalidateTag event to the proxy for that tag.
Atoms are used heavily for ICCCM communication. Once the proxy knows the string to atom mapping, it has no need to send subsequent requests for this atom to the server.
Colorname/RGB mappings are constant, so once the proxy sees the response from LookupColor, it need not forward any subsequent requests.
Clients often use the same color cells, so once a read-only color allocation has occurred, the proxy knows what RGB values should be returned to the client. The proxy doesn't need to forward any AllocColor requests it can resolve, but it must tell the server to modify the color cell's reference count. LbxIncre mentPixel is used to support this.
For all three classes of short-circuiting, the proxy must still tell the server a request has occurred, so that the request sequence numbers stay in sync. This is done with LbxModifySequence.
Sequence numbers cause the major complication with short-circuiting. X guarantees that any replies, events or errors generated by a previous request will be sent before those of a later request. This means that any requests that can be handled by the proxy must have their reply sent after any previous events or errors.
If a proxy's applications do not require strict adherence to the X protocol ordering of errors or events, a proxy might provide further optimization by avoiding the overhead of maintaining this ordering, however, the resulting protocol is not strictly X11 compliant.
The server should process delta requests in the order that they appear on the LBX connection. If the server does not maintain the interclient request order for requests sent by the proxy, it must still obey the semantics implied by the interclient request order so that the delta cache functions correctly.
The server can affect the multiplexing of clients by the proxy using the LbxListenToOne and LbxLis tenToAll messages. This is useful during grabs, since the master connection can not be blocked during grabs like other clients. The proxy is responsible for tracking server grabs issued by its clients so that the proxy can multiplex the client streams in an order executable by the server.
Replies must be ordered in the multiplexed data stream from the server to the proxy such that the reply car rying tagged data precedes replies that refer to that tagged data.
The server and the proxy each keep per-proxy request and response caches. The response cache contains events, errors and replies. All messages are saved in the appropriate delta cache if they are of an appropriate type and more than 8 bytes long but fit within the delta cache. The number of entries in the delta cache and the maximum saved message size are negotiated in the LbxStartProxy request.
The LBX requests that are never stored in the request delta cache are the LbxQueryVersion, Lbx StartProxy, LbxSwitch, LbxNewClient, LbxAllowMotion, LbxDelta, LbxQueryExten sion, LbxPutImage, LbxGetImage, LbxBeginLargeRequest, LbxLargeRequestData, LbxEndLargeRequest and LbxInternAtoms requests. The responses that are never stored in the response cache are LbxSwitchEvent and LbxDeltaResponse. The message carried by a delta message is also cached, if it meets the other requirements. Messages after the LbxStartProxy request are cached starting at index 0, and incrementing the index, modulo the number of entries, thereafter. The request and response caches are independently indexed.
If the current message is cachable and the same length as a message in the corresponding delta cache, a delta message may be substituted in place of the original message in the protocol stream.
The XC-ZLIB compressor is presented with a simple byte stream - the X and LBX message boundaries are not apparent. The data is broken up into fixed sized blocks. Each block is compressed using zlib 1.0 (by Gailly & Adler), then a two byte header is prepended, and then the entire packet is transmitted. The header has the following information:
out[0] = (length & 0xfff) >> 8 | ((compflag) ? 0x80 : 0);
out[1] = length & 0xff;
Bool XLbxQueryVersion(display, major_version_return, minor_version_return)
Display * display;
int * major_version_return;
int * minor_version_return;
display Specifies the connection to the X server.
major_version_return Returns the extension major version number.
minor_version_return Returns the extension minor version number.
The XLbxQueryVersion function determines if the LBX extension is present. If the extension is not
present, XLbxQueryVersion returns False; otherwise, it returns True. If the extension is present,
XLbxQueryVersion returns the major and minor version numbers of the extension as supported by the X
server.
Bool XLbxQueryExtension(display, major_opcode_return, first_event_return, first_error_return)
Display * display; Specifies the connection to the X server.
int * major_opcode_return; Returns the major opcode.
int * first_event_return; Returns the first event code.
int * first_error_return; Returns the first error code.
The XLbxQueryExtension function determines if the LBX extension is present. If the extension is not
present, XLbxQueryExtension returns False; otherwise, it returns True. If the extension is present,
XLbxQueryExtension returns the major opcode for the extension to major_opcode_return, the base
event type code to first_event_return, and the base error code to first_error_return; otherwise, the return val
ues are undefined.
int XLbxGetEventBase(display)
Display * display; Specifies the connection to the X server.
The XLbxGetEventBase function returns the base event type code if the extension is present; otherwise,
it returns -1.
The following additional types are defined by this extension:
DIFFITEM
1 CARD8 offset
1 CARD8 diff
where (in order of precedence):
(0 <= in <= A(95)) && !(in % A(5)) out = 0x5a + (in / A(5))
A(105) <= in <= A(360) && !(in % A(15)) out = 0x67 + (in / A(15))
-A(100) <= in <= -A(5) && !(in % A(5)) out = 0xa6 + (in / A(5))
-A(360) < in <= -A(105) && !(in % A(15)) out = 0x98 + (in / A(15))
-A(360) < in <= A(360) out[0] = in >> 8; out[1] = in
[x, y: LBXINT16,
width, height: LBXCARD16,
angle1, angle2: LBXANGLE]
Within a list of arcs, after the first arc, x and y are relative to the corresponding fields of the prior arc.
where:
0x0000 <= in < 0x00F0 CARD8
0x00F0 <= in < 0x10F0 out[0] = 0xF0 | ((in - 0xF0) >> 8)
out[1] = in - 0xF0
[ gc-cache-index, drawable-cache-index: CARD4 ]
drawable: DRAWABLE /* present only if drawable-cache-index == 0 */
gc: GC] /* present only if gc-cache-index == 0 */
cache-entries: LBXGCANDDRAWENT
updates: LBXGCANDDRAWUPDATE
where:
0xF790 <= in < 0xFF90 out[0] = 0x80 | (((in + 0x70) >> 8) & 0x0F)
out[1] = in + 0x70
0xFF90 <= in < 0x0080 CARD8
0x0080 <= in < 0x0880 out[0] = 0x80 | (((in - 0x80) >> 8) & 0x0F)
out[1] = in - 0x80
where:
0xFE00 <= in < 0x0000 out[0] = 0xF0 | (((in + 0x1000) >> 8) & 0x0F)
out[1] = in + 0x1000
0x0000 <= in < 0x00F0 CARD8
0x00F0 <= in < 0x0EF0 out[0] = 0xF0 | ((in - 0xF0) >>8)
out[1] = in - 0xF0
Within a list of points, after the first rectangle, x and y are relative to the corresponding fields of the prior point.
[x, y: LBXINT16,
width, height: LBXCARD16]
Within a list of rectangles, after the first rectangle, x and y are relative to the corresponding fields of the prior rectangle.
There is one error, LbxClient. This error indicates that the client field of an LBX request was invalid, or that the proxy's connection was in an invalid state for a start or stop proxy request.
There is one request that is expected to be used by the client or the proxy: LbxQueryExtension.
The following requests are expected to be used only by the proxy, and are instigated by the proxy: Lbx StartProxy, LbxStopProxy, LbxNewClient, LbxSwitch, LbxCloseClient, LbxModify Sequence, LbxAllowMotion, LbxInvalidateTag, LbxTagData and LbxQueryTag.
All other requests are sent by the proxy to the LBX server and are instigated by reception of an X request from the client. They replace the X request.
-->
majorVersion: CARD16
minorVersion: CARD16
The encoding of this request is on page 30.
nbytes: CARD32
name: STRING8
-->
num-requests: CARD8
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
reply-mask: LISTofMASK /* optional */
event-mask:LISTofMASK /* optional */
Errors: Alloc
This request determines if the named extension is present. If so, the major opcode for the extension is returned, if it has one. Otherwise, zero is returned. Any minor opcode and the request formats are specific to the extension. If the extension involves additional event types, the base event type code is returned. Other wise, zero is returned. The format of events is specific to the extension. If the extension involves additional error codes, the base error code is returned. Otherwise, zero is returned. The format of additional data in the errors is specific to the extension.
In addition, the number of requests defined by the named extension is returned. If the number of requests is nonzero, and if the information is available, reply-mask and event-mask will be included in the reply. The reply-mask represents a bit-wise one-to-one correspondence with the extension requests. The least signifi cant bit corresponds to the first request, and the next bit corresponds to the next request, and so on. Each ele ment in the list contains eight meaningful bits, except for the last element, which contains eight or fewer meaningful bits. Unused bits are not guaranteed to be zero. The bit corresponding to a request is set if the request could generate a reply, otherwise it is zero. In the same way, the event-mask represents a bit-wise one-to-one correspondence with the extension requests. A bit is set if the corresponding request could result in the generation of one or more extension or X11 events. If reply-mask is present in the reply, event-mask will also be present.
The encoding of this request is on page 41.
options: LISTofOPTION
-->
choices: LISTofCHOICE
Errors: LbxClient, Alloc
OPTION [optcode: CARD8,
len: OPTLEN,
option: (See Table 1, "StartProxy Options," on page 10) ]
CHOICE [optcode: CARD8,
len: OPTLEN,
choice: (See Table 1, "StartProxy Options," on page 10) ]
-------------------------------------------------------------------------------------- | optcode | option | choice | default | ====================================================================================== | delta-proxy | DELTAOPT | DELTACHOICE | entries=16, maxlen=64 | -------------------------------------------------------------------------------------- | delta-server | DELTAOPT | DELTACHOICE | entries=16, maxlen=64 | -------------------------------------------------------------------------------------- | stream-comp | LISTofNAMEDOPT | INDEXEDCHOICE | No Compression | -------------------------------------------------------------------------------------- | bitmap-comp | LISTofSTRING8 | LISTofINDEXEDOPT | No Compression | -------------------------------------------------------------------------------------- | pixmap-comp | LISTofPIXMAPMETHOD | LISTofPIXMAPCHOICE | No Compression | -------------------------------------------------------------------------------------- | use-squish | BOOL | BOOL | True | -------------------------------------------------------------------------------------- | use-tags | BOOL | BOOL | True | -------------------------------------------------------------------------------------- | colormap | LISTofSTRING8 | INDEXEDCHOICE | No Colormap Grabbing | -------------------------------------------------------------------------------------- | extension | NAMEDOPT | INDEXEDCHOICE | Extension Disabled | --------------------------------------------------------------------------------------StartProxy Options
DELTAOPT [minN, maxN, prefN: CARD8
minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen: CARD8]
DELTACHOICE [entries, maxlen: CARD8]
INDEXEDCHOICE [index: CARD8,
data: LISTofBYTE]
INDEXEDOPT [index, opcode: CARD8]
NAMEDOPT [name: STRING8,
detail: LISTofBYTE]
OPTLEN 1 or 3 CARD8
where:
(0 < in <= 0xFF): out = in
(0 <= in<= 0xFFFF): out[0] = 0; out[1] = in >> 8; out[2] = in& 0xFF;
PIXMAPMETHOD [name: STRING8,
format-mask: BITMASK,
depths: LISTofCARD8]
PIXMAPCHOICE [index, opcode: CARD8,
format-mask: BITMASK,
depths: LISTofCARD8]
The proxy gives the preferred protocol options in the request. The server chooses from the given options and informs the proxy which to use. The options may be listed in any order, and the proxy may choose which options to negotiate. If an option is not successfully negotiated, the default is used.
The server delta cache and proxy delta caches can be configured for number of entries, and the length of entries. (See "Delta cache" on page 4 for details.) The delta caches are configured using the delta-server and delta-proxy options. To configure a cache, the proxy sends the minimum, maximum and preferred values for the number of cache entries, (minN, maxN, prefN), and the length of the cache entries, (minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen). The server's reply fields, entries and maxlen, contains the values to use. These values must be within the ranges specified by the proxy. The server may also specify an entries value of 0 to disable delta caching. The cache entry lengths are specified in units of 4 bytes.
The stream compression algorithm is selected using the stream-comp option. (Stream compression is described in "Stream Compression" on page 5.) Each algorithm has a name that follows the naming conven tions in "Algorithm Naming" on page 29. To negotiate using the stream-comp option, the proxy lists its available compressors. For each candidate algorithm, the proxy sends the name in the name field, and uses the detail field to send any additional data specific to each compression algorithm. The reply contains a 0- based index into the list of algorithms to indicate which algorithm to use, followed by data specific to that algorithm.
Bitmap compression is negotiated using the bitmap-comp option. The proxy sends a list of names of avail able algorithms, and the server reply lists the algorithms to use. For each bitmap algorithm in the reply, a 0- based index into the list of algorithms indicates the algorithm, and the opcode field gives the value for use in requests. The algorithm names follow the conventions in "Algorithm Naming" on page 29.
Pixmap compression is negotiated using the pixmap-comp option. The proxy sends a list of available algo rithms. For each algorithm, the list includes, the name, a bitmask of supported formats, and a list of depths that the format supports. The server reply lists the algorithms to use. For each pixmap algorithm in the reply, the reply contains a 0-based index into the list of proxy algorithms, the opcode to use in requests when refer ring to this algorithm, a mask of valid formats, and a list of valid depths. Algorithm names follow the con ventions in "Algorithm Naming" on page 29.
Squishing is negotiated using the use-squish option. If the proxy desires squishing, it sends a true value. The reply from the server indicates whether to do squishing, and will indicate squishing only if use-squish is set to true in the request.
Tag caching, described in "Tags" on page 2, is negotiated using the use-tag option. If the proxy desires tag caching, it sends a true value. The reply from the server indicates whether to do tag caching, and will demand caching only if use-tag is set to true in the request.
The colormap option is used to negotiate what color matching algorithm will be used by the proxy when the proxy uses the LbxAllocColor request to allocate pixels in a grabbed colormap. To negotiate using the colormap option, the proxy lists the names of available colormap algorithms. The choice in the reply con tains a 0-based index into the list of algorithms to indicate which algorithm to use, followed by data specific to that algorithm. If no colormap algorithm is successfully negotiated, then the LbxAllocColor, LbxGrabCmap, and LbxReleaseCmap requests will not be used.
The extension option is used to control extensions to LBX. These extensions may, for example, enable other types of compression. To negotiate an extension, the name of the extension is sent, followed by any data spe cific to that extension. The extension name follows the conventions in "Algorithm Naming" on page 29. The extension option may occur multiple times in the start proxy message, since multiple extensions can be negotiated. The reply to an extension option contains the zero-based index of the extension option, as counted in the LbxStartProxy message. This index is followed by extension-specific information. The server does not respond to extensions it does not recognize.
An LbxClient error is returned when a client which is already communicating through an LBX proxy to the X server sends a LbxStartProxy request.
The encoding for this request is on page 31.
Errors: LbxClient
The encoding for this request is on page 33.
An LbxClient error is returned if the requesting client is not an LBX proxy.
byte-order: CARD8
client-id: CARD32
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
-->
Core X reply (if connection is rejected)
OR
success: BOOL
change-type: {NoDeltas, NormalClientDeltas, AppGroupDeltas}
protocol-major-version: CARD16
protocol-minor-version: CARD16
tag-id: CARD32
length: CARD16
connection-data: CONINFO or CONDIF or CONDIFROOT
where:
CONINFO: (the "additional data" portion of the core connection reply for successes)
CONDIF: [resource-id-base: CARD32,
root-input-masks: LISTofSETofEVENT]
CONDIFROOT: [resource-id-base: CARD32,
root: WINDOW
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
root-input-masks: LISTofSETofEVENT]
This request, which is sent by the proxy over the control connection, creates a new virtual connection to the server.
Much of the information in the LbxNewClient request and reply is identical to the connection setup and reply information in the core X protocol.
For the LbxNewClient request, the field unique to LBX is client-id. For the LbxNewClient reply, tag- id and change-type are fields unique to LBX, and the contents of connection-data may be different in LBX from the core X protocol (see below).
The proxy assigns each virtual connection a unique identifier using the client-id field in the LbxNewCli ent request. This client-id is used in the LBX protocol to specify the current client (see the LbxSwitch request and the LbxSwitchEvent). client-id 0 is reserved for the proxy control connection. An LbxCli ent error will result if the LbxNewClient request contains a client-id of 0 or an already in use client-id.
If the server rejects this new virtual connection, the server sends a core X connection failure reply to the proxy. The current version of LBX does not support the return of an Authenticate reply.
If the change-type field is set to NoDeltas, then connection-data is sent using the CONINFO structure, which is identical to the additional data of the core connection reply. If the tag-id is non-zero, then the con nection-data is stored by the proxy using this tag value. Tagged connection data must be stored by the proxy, and can not be invalidated by the proxy until an LbxInvalidateTag event is received for that tag.
When the change-type field is not set to NoDeltas, then connection data is sent as changes against connec tion information previously sent to the proxy. The tag-id field, if non-zero, has the tag of the previously sent data to apply the changes to. A zero tag-id indicates that the changes are with respect to the connection infor mation sent when the proxy connected to the server.
If the change-type field is set to NormalClientDeltas, then connection-data is sent using the CONDIF structure. The values in the CONDIF structure are substituted for the identically named fields of the connec tion information for the new connection.
If the change-type field is set to AppGroupDeltas, then connection-data is sent using the CONDI FROOT structure. The root, root-visual, and default-colormap fields, when nonzero, are substituted for the corresponding fields in the reference connection information. The white-pixel and black-pixel fields are sub stituted only when the default-colormap field of the reply is non-zero. When default-colormap field of the reply is zero, so are white-pixel and black-pixel. The first entry in the root-input-masks field is the current- input-mask for the default root window. The remaining entries in root-input-masks are input masks for non- video screens, as defined by the X Print Extension. The number of non-video screens is one less than the number of entries in root-input-masks. These screens are at the end of screen list in the reference connection information.
The encoding for this request is on page 33.
client: CARD32
Errors: LbxClient
The encoding for this request is on page 34.
client: CARD32
Errors: LbxClient
If the client making the request is not the proxy, or if the client identifier sent in the request was not previ ously sent in a LbxNewClient request, an LbxClient error is returned.
The encoding for this request is on page 33.
--> The sync request causes the server to send a reply when all requests before the sync request have been pro cessed.
The encoding for this client is on page 46.
adjust: CARD32
Errors: None
The encoding for this client is on page 34.
num: CARD32
Errors: None
The encoding for this request is on page 34.
tag: CARD32
The encoding for this request is on page 35.
tag: CARD32
real-length: CARD32
data: LISTofBYTE
The encoding for this request is on page 39.
cmap: Colormap
->
smart-grab: BOOL
large-pixel: BOOL /* optional */
auto-release: BOOL /* optional */
three-channels: BOOL /* optional */
bits-per-rgb: CARD4 /* optional */
cells: LISTofCHAN /* optional */
where:
CHAN: LISTofLBXPIXEL
LBXPIXEL: PIXELPRIVATE or PIXELPRIVATERANGE or
PIXELALLOC or PIXELALLOCRANGE
PIXEL: CARD8 or CARD16
PIXELPRIVATE: [ pixel: PIXEL ]
PIXELPRIVATERANGE: [ first-pixel, last-pixel: PIXEL]
PIXELALLOC: [ pixel: PIXEL,
color: COLORSINGLE or COLORTRIPLE]
PIXELALLOCRANGE: [ first-pixel, last-pixel: PIXEL,
colors: LISTofCOLORSINGLE or LISTofCOLORTRIPLE]
COLORSINGLE: [ value: CARD8 or CARD16 ]
COLORTRIPLE: [ r, g, b: COLORSINGLE]
Errors: Colormap
Once the proxy has received the reply, it can use the LbxAllocColor request to allocate new colormap cells without the performance penalty of round trips. The proxy is still permitted to use the normal colormap and LbxIncrementPixel requests while the colormap is grabbed. The grab is valid across all virtual connections of the proxy.
The LbxGrabCmap request is limited to colormaps for the visual types negotiated as part of the colormap algorithm negotiation in the start proxy request at connection setup.
The server and other proxies may not allocate new colormap cells in the colormap while the colormap is grabbed by this proxy. If the server or another proxy needs to allocate new colormap cells, the server sends a LbxReleaseCmap event to the proxy holding the grab, which then issues an LbxReleaseCmap request.
The server and other proxies may free colormap cells in a colormap grabbed by a proxy. The server will send an LbxFreeCells event to the proxy that currently has the colormap grabbed when the cell reference count reaches 0.
If the colormap is a of a static visual type, such as StaticGray, StaticColor, GrayScale, or TrueColor, then the proxy's grab is immediately released by the server, and the proxy must use LbxIn crementPixel requests in place of LbxAllocColor requests for this colormap.
If the cmap field does not refer to a valid colormap or the colormap is already grabbed by this proxy then a Colormap error is generated.
The reply describes the contents of the colormap via several arguments and a descriptive list containing one or three channels, with each channel describing allocations in the colormap.
The large-pixel argument, if True, specifies that PIXEL indices will be listed as CARD16 quantities instead of CARD8. The auto-release field, if True, indicates that this colormap is of a static visual type and the proxy's grab is immediately released by the server.
If three-channels is False, a single channel is enclosed and color values are described using COLORTRI PLE, which has fields for red, green and blue. A single channel is used when the visual type is not Direct Color or TrueColor.
If three-channels is True, separate red, green and blue channel lists are enclosed, for describing a Direct Color or TrueColor colormap. Color values for entries in each channel are sent using COLORSINGLE and the corresponding PIXEL value refers to the RGB subfield of the current channel, as defined by the cor responding red-mask, green-mask and blue-mask of the visual.
The bits-per-rgb value is one less than the bits-per-rgb-value field of the visual that the colormap belongs to. If the value is 7 or less, then COLORSINGLE values in the descriptive list are sent using CARD8 fields. Otherwise these values are sent using CARD16 fields.
The list describing current colormap allocations contains entries of the following types:
An LBXPIXELPRIVATE entry indicates that the pixel in the pixel field is unavailable for allocation.
An LBXPIXELPRIVATERANGE entry indicates that a contiguous range of pixels are unavailable for allo cation. The range is first-pixel to last-pixel, and includes last-pixel.
An LBXPIXELALLOC entry indicates that the pixel in the pixel field is allocated as a read-only pixel. The color field carries the color information of the pixel.
An LBXPIXELALLOCRANGE entry indicates that a contiguous range of pixels are allocated as read-only. The range starts first-pixel to last-pixel, and includes last-pixel. These fields are followed by a list of COL ORSINGLE or COLORTRIPLE, depending on the value of three-channels.
A NEXTCHANNEL entry indicates that the next channel of the colormap will be described.
A LISTEND entry indicates the end of the colormap description.
All pixels not described in the reply are unallocated.
The encoding for this request is on page 44.
cmap: Colormap
The proxy must remember the state of the colormap when the LbxReleaseCmap request is issued if this proxy may at some future time issue another LbxGrabCmap request on this colormap before the state of the colormap changes.
The encoding for this request is on page 46.
count: CARD16
names: LISTofSTRING8
-->
atoms: LISTofATOM
Errors: Alloc
The encoding for this request is on page 43.
cmap: Colormap
pixel: CARD32
red, green, blue: CARD16
The pixel field identifies the colormap cell to allocate. The red, green, and blue fields are the hardware spe cific color values of the corresponding fields of the core AllocColor request. The mapping to hardware specific colormap values by the proxy is performed using the color algorithm negotiated by LbxStart Proxy.
For colormaps of static visual types, the LbxIncrementPixel request is used instead of LBX Alloc Color.
If the cmap field does not identify a grabbed colormap then a BadAccess error is produced. If the pixel field refers to a read-write entry, or the pixel field refers to a pixel outside of the range of this colormap, a BadAlloc error is produced.
The encoding for this request is on page 46.
cmap: COLORMAP
pixel: CARD32
Errors: None
The encoding for this request is on page 34.
count: CARD8
cache-index: CARD8
diffs: LISTofDIFFITEM
The encoding for this request is on page 34.
-->
keyspermod: CARD8
tag: CARD32
keycodes: LISTofKEYCODE /* optional */
The encoding for this request is on page 35.
firstKeyCode: KEYCODE
count: CARD8
-->
keysperkeycode: CARD8
tag: CARD32
keysyms: LISTofKEYSYM /* optional */
Errors: Value
The encoding for this request is on page 37.
window: WINDOW
-->
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable, Viewable}
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors: Window
.The encoding for this request is on page 43.
font: FONTABLE
-->
compression: BOOL
tag: CARD32
font-info: FONTINFO /* optional */
char-infos: LISTofCHARINFO or LISTofLBXCHARINFO /* optional */
where:
LBXCHARINFO: [left-side-bearing: INT6
right-side-bearing: INT7
character-width: INT6
ascent: INT6
descent: INT7]
Errors: Font,Alloc
See "Tag Substitution in Requests" on page 2 for a description of the tag field and optional fields.
The compression field is True if the char-infos field is represented using LBXCHARINFO.
The per-character information will be encoded in an LBXCHARINFO when, for every character, the charac ter-width, left-side-bearing, and ascent can each be represented in not more than 6 bits, and the right-side- bearing and descent can each be represented in not more than 7 bits, and the attributes field is identical the attributes field of the max_bounds of the font_info field of the font.
The encoding for this request is on page 37.
window: WINDOW
property: ATOM
type: ATOM
format: {0,8,16,32}
mode: {Replace, Prepend, Append}
nUnits: CARD32
-->
tag: CARD32
If the mode field is Prepend or Append, the tag refers only to the prepended or appended data.
If the tag in the reply is zero, then the change was ignored by the server, as defined in the security extension. The proxy should dump the associated data, since the server will never ask for it.
The encoding for this request is on page 38.
window: WINDOW
property: ATOM
type: ATOM or AnyPropertyType
long-offset: CARD32
long-length: CARD32
delete: CARD8
-->
type: ATOM or None
format: {0, 8, 16, 32}
bytes-after: CARD32
nItems: CARD32
tag: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
The LbxGetProperty request has the same arguments as the core GetProperty request. The reply for LbxGetProperty has all of the fields from the core GetProperty reply, but has the additional fields of nItems and tag.
In order to utilize tags in LbxGetProperty for a specific property, the server must first send the complete property data to the proxy and associate this data with a tag. More precisely, the server sends an LbxGet Property reply with a new tag, nItems set to the number of items in the property, the size of the property data in the reply length field, and the complete property data in value. The proxy stores the property data in its tag cache and associates it with the specified tag.
In response to future LbxGetProperty requests for the same property, if the server thinks that the proxy has the actual property data in its tag cache, it may choose to send an LbxGetProperty reply without the actual property data. In this case, the reply would include a non-zero tag, a zero reply length, and no data for value.
If the server chooses not to generate a tagged reply to LbxGetProperty, or for some reason is unable to do so, it would send a reply with a tag of zero, the size of the property data in the reply length field, and the complete property data in value.
The encoding for this request is on page 38.
gc-and-drawable: LBXGCANDDRAWABLE
points: LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.
The proxy will convert the representation of the points to be relative to the previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on page 35.
gc-and-drawable: LBXGCANDDRAWABLE
points: LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.
The proxy will convert the representation of the points to be relative to the previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on page 35.
gc-and-drawable: LBXGCANDDRAWABLE
segments: LISTofLBXSEGMENT
where:
LBXSEGEMENT; [x1, y1, x2, y2: LBXINT16]
Errors: Alloc and those given for the corresponding X request.
For segments other than the first segment of the request, [x1, y1] is relative to [x1, y1] of the previous seg ment. For all segments, [x2, y2] is relative to that segment's [x1, y1].
The encoding for this request is on page 35.
gc-and-drawable: LBXGCANDDRAWABLE
rectangles: LISTofLBXRECTANGLE
Errors: Alloc and those given for the corresponding X request.
The encoding for this request is on page 36.
gc-and-drawable: LBXGCANDDRAWABLE
arcs: LISTofLBXARC
Errors: Alloc and those given for the corresponding X request.
The encoding for this request is on page 36.
gc-and-drawable: LBXGCANDDRAWABLE
rectangles: LISTofLBXRECTANGLE
Errors: Alloc and those given for the corresponding X request.
The encoding for this request is on page 36.
gc-and-drawable: LBXGCANDDRAWABLE
arcs: LISTofLBXARC
Errors: Alloc and those given for the corresponding X request.
The encoding for this request is on page 37.
gc-and-drawable: LBXGCANDDRAWABLE
shape: BYTE
points: LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.
The proxy will convert the representation of the points to be relative to the previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on page 36.
srcCache: CARD8 /* source drawable */
gc-and-drawable: LBXGCANDDRAWABLE
src-Drawable: CARD32
src-x: LBXPINT16
src-y: LBXPINT16
width: LBXCARD16
height: LBXCARD16
dst-x: LBXPINT16
dst-y: LBXPINT16
Errors: Those given for the corresponding X request.
The encoding for this request is on page 39.
bit-plane: CARD32
src-cache: CARD8 /* cache reference for source drawable */
gc-and-drawable: LBXGCANDDRAWABLE
src-drawable: CARD32
src-x: LBXPINT16
src-y: LBXPINT16
width: LBXCARD16
height: LBXCARD16
dst-x: LBXPINT16
dst-y: LBXPINT16
Errors: Those given for the corresponding X request.
The encoding for this request is on page 40.
gc-and-drawable: LBXGCANDDRAWABLE
x: LBXPINT16
y: LBXPINT16
items: LISTofTEXTITEM8
Errors: Alloc, and those given for the corresponding X request.
The encoding for this request is on page 40.
gc-and-drawable: LBXGCANDDRAWABLE
x: LBXPINT16
y: LBXPINT16
items: LISTofTEXTITEM16
Errors: Alloc, and those given for the corresponding X request.
The encoding for this request is on page 40.
gc-and-drawable: LBXGCANDDRAWABLE
nChars: CARD8
x: LBXPINT16
y: LBXPINT16
string: STRING8
Errors: Alloc, and those given for the corresponding X request.
The encoding for this request is on page 40.
nChars: CARD8
gc-and-drawable: LBXGCANDDRAWABLE
x: LBXPINT16
y: LBXPINT16
string: STRING16
Errors: Alloc, and those given for the corresponding X request.
The encoding for this request is on page 41.
compression-method: CARD8
format: {Bitmap, XYPixmap, ZPixmap} /* packed */
gc-and-drawable: LBXGCANDDRAWABLE
width, height: LBXCARD16
dst-x, dst-y: LBXPINT16
depth: CARD8 /* packed */
left-pad: CARD8 /* packed */
pad-bytes: CARD8 /* packed */
data:LISTofBYTE
Errors: Alloc, Value
The encoding for this request is on page 41.
drawable: DRAWABLE
x, y: INT16
width, height: CARD16
plane-mask: CARD32
format: {XYPixmap, ZPixmap}
-->
depth: CARD8
x-length: CARD32
visual: VISUALID or None
compression-method: CARD8
data: LISTofBYTE
Errors: Alloc,Match,Value
The compression-method field contains the opcode of the compression method used in the reply. The com pression opcodes are supplied in the LbxStartProxy reply. The x-length field contains the length of the uncompressed version of the reply in 4 byte units.
A Value error is returned if the format is not recognized by the X server. A Match error is returned under the same circumstances as described by the GetImage request.
The encoding for this request is on page 42.
large-request-length: CARD32
Errors: Alloc
After a LbxBeginLargeRequest request is sent, multiple LbxLargeRequestData requests are sent to transport all of the data in the large request, and finally an LbxEndLargeRequest request is sent. The large-request-length field expresses the total length of the transported large request, expressed as the number of bytes in the transported request divided by four.
The encoding for this request is on page 42.
data: LISTofBYTE
Errors: Alloc
The encoding for this request is on page 43.
Errors: Length, Alloc
The encoding for this request is on page 43.
client: CARD32
The encoding for this event is on page 46.
client: CARD32
The encoding for this event is on page 47.
tag: CARD32
tag-type: {Modmap, Keymap, Property, Font, ConnInfo}
The encoding for this event is on page 47.
tag: CARD32
tag-type: {Property}
The encoding for this event is on page 47.
client: CARD32 or 0xffffffff
When the client grabbing the server is managed through the proxy, the proxy will permit messages from itself and the grabbing client to be sent immediately to the server, and may buffer requests from other clients of the proxy. The client is identified in the event.
When the client grabbing the server is not managed through the proxy, the client field in the event will be 0xffffffff. The proxy will communicate with the server, and it may buffer requests from other clients. The proxy will continue to handle new connections while the server is grabbed.
The server will send ListenToAll to the proxy when the server is ungrabbed. There is no time-out for this interval in the protocol.
The encoding for this event is on page 47.
The encoding for this event is on page 47.
deltaTime: CARD8
deltaX: INT8
deltaY: INT8
The encoding for this event is on page 48.
deltaX: INT8
deltaY: INT8
deltaTime: CARD16
deltaSequence: CARD16
.The encoding for this event is on page 48.
colormap: Colormap
The encoding for this event is on page 48.
colormap: Colormap
pixelStart, pixelEnd: CARD32
The pixelStart and pixelEnd fields of the event denote a continuous range of cells that were freed.
The encoding for this event is on page 48.
count: CARD8
cache-index: CARD8
diffs: LISTofDIFFITEM
The encoding for this event is on page 49.
Each algorithm has a unique name, which is a STRING8, of the following form:
<organization>-<some-descriptive-name>
The organization field above is the organization name as registered in section 1 of the X Registry (the regis try is provided as a free service by the X Consortium.) This prevents conflicts among different vendor's extensions.
As an example, the X Consortium defines a zlib-based stream compression algorithm called XC-ZLIB.
As in the X protocol, in various cases, the number of bytes occupied by a component will be specified by a lowercase single-letter variable name instead of a specific numeric value, and often some other component will have its value specified as a simple numeric expression involving these variables. Components specified with such expressions are always interpreted as unsigned integers. The scope of such variables is always just the enclosing request, reply, error, event, or compound type structure.
For unused bytes, the encode-form is:
N unused
p unused, p=pad(E)
pad(E) = (4 - (E mod 4)) mod 4
In many of the encodings, the length depends on many variable length fields. The variable L is used to indi cate the number of padded 4 byte units needed to carry the request. Similarly, the variable Lpad indicates the number of bytes needed to pad the request to a 4 byte boundary.
For counted lists there is a common encoding of NLISTofFOO:
NLISTofFOO
1 m num items
m LISTofFOO items
LBXGCANDDRAWUPDATE
4 or 0 DRAWBLE optional drawable
4 or 0 GC optional GC
LBXGCANDDRAWABLE
8 LBXGCANDDRAWENT cache-entries
8 unused
m LBXGCANDDRAWUPDATE optional GC and Drawable
1 0 Error
1 CARD8 error-base + 0
2 CARD16 sequence number
4 unused
2 CARD16 lbx opcode
1 CARD8 major opcode
21 unused
1 CARD8 opcode
1 0 lbx opcode
2 1 request length
-->
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 major version
2 CARD16 minor version
20 unused
1 CARD8 opcode
1 1 lbx opcode
2 L request length
n NLISTofOPTION-REQUEST options
p unused, p=pad(n)
1 OPTCODE option-code
m OPTLEN option-request-byte-length, (b=m+a+1)
a DELTAOPT or option
NLISTofNAMEDOPT or
NLISTofSTR or
NLISTofPIXMAPMETHOD or
BOOL
1 OPTCODE option-code
0 LbxOptionDeltaProxy
1 LbxOptionDeltaServer
2 LbxOptionStreamCompression
3 LbxOptionBitmapCompression
4 LbxOptionPixmapCompression
5 LbxOptionMessageCompression /* also known as squishing */
6 LbxOptionUseTags
7 LbxOptionColormapAllocation
255 LbxOptionExtension
OPTLEN
1 CARD8 b (0 < b <= 255)
OPTLEN
1 0 long length header
1 c length0, c = b >> 8
1 d length1, d= b & #xff
1 CARD8 min-cache-size
1 CARD8 max-cache-size
1 CARD8 preferred-cache-size
1 CARD8 min-message-length
1 CARD8 max-message-length (in 4-byte units)
1 CARD8 preferred-message-length
f STR type-name
1 g+1 option-data-length
g LISTofBYTE option-data (option specific)
h STR name
1 BITMASK format mask
1 j depth count
j LISTofCARD8 depths
-->
1 1 Reply
1 CARD8 count
0xff options in request cannot be decoded
2 CARD16 sequence number
4 (a+p-32)/4 reply length
a LISTofCHOICE options-reply
p unused, if (n<24) p=24-n else p=pad(n)
1 CARD8 request-option-index
b OPTLEN reply-option-byte-length
c DELTACHOICE or choice
INDEXEDCHOICE or
NLISTofINDEXEDOPT or
NLISTofPIXMAPCHOICE or
BOOL or
INDEXEDCHOICE
DELTACHOICE
1 CARD8 preferred cache size
1 CARD8 preferred message length in 4-byte units
1 CARD8 index
d LISTofBYTE data
1 CARD8 index
1 CARD8 opcode
1 BITMASK format mask
e NLISTofCARD8 depths
1 CARD8 opcode
1 2 lbx opcode
2 1 request length
1 CARD8 opcode
1 3 lbx opcode
2 2 request length
4 CARD32 client
1 CARD8 opcode
1 4 lbx opcode
2 L request length
4 CARD32 client
The remaining bytes of the request are the core connection setup.
-->
If the connection is rejected, a core connection reply is sent. Otherwise the reply has the form:
1 BOOL success
1 change type
0 no-deltas
1 normal-client-deltas
2 app-group-deltas
2 CARD16 major version
2 CARD16 minor version
2 1 + a length
4 CARD32 tag id
For no-deltas, the remaining bytes are the "additional data" bytes of the core reply. (a = length of core reply, in 4 byte quantities).
For normal-client-deltas, the additional bytes have the form, with a length (a = 1 +b):
4 CARD32 resource id base
4b LISTofSETofEVENT root input masks
4 CARD32 resource id base
4 WINDOW root id base
4 VISUALID visual
4 COLORMAP colormap
4 CARD32 white pixel
4 CARD32 black pixel
4c LISTofSETofEVENT root input masks
1 CARD8 opcode
1 5 lbx opcode
2 2 request length
4 CARD32 client
1 CARD8 opcode
1 6 lbx opcode
2 2 request length
4 CARD32 offset to sequence number
1 CARD8 opcode
1 7 lbx opcode
2 2 request length
4 CARD32 number of MotionNotify events
1 CARD8 opcode
1 8 lbx opcode
2 3 request length
4 COLORMAP colormap
4 CARD32 pixel
1 CARD8 opcode
1 9 lbx opcode
2 1+(2n +p+2)/4 request length
1 n count of diffs
1 CARD8 cache index
2n LISTofDIFFITEM offsets and differences
p unused, p=pad(2n + 2)
1 CARD8 opcode
1 10 lbx opcode
2 1 request length
-->
1 1 Reply
1 n keycodes-per-modifier
2 CARD16 sequence number
4 2n reply length
4 CARD32 tag
20 unused
8n LISTofKEYCODE keycodes
1 CARD8 opcode
1 12 lbx opcode
2 2 request length
4 CARD32 tag
1 CARD8 opcode
1 13 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 14 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 15 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXSEGMENT segments (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 16 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXRECTANGLE rectangles (n is data-dependent)
p 0 unused, p=pad(m+n)
1 CARD8 opcode
1 17 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXARCS arcs (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 18 lbx opcode
2 1+(3+m+n+p)/4 request length
1 LBXGCANDDRAWENT cache entries
1 shape
0 Complex
1 Nonconvex
2 Convex
1 p pad byte count
m LBXGCANDDRAWUPDATE optional gc and drawable
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 19 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXRECTANGLE rectangles (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 20 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXARC arcs (n is data-dependent)
p 0 unused, p=Lpad
1 CARD8 opcode
1 21 lbx opcode
2 2 request length
1 KEYCODE first keycode
1 m count
2 unused
-->
1 1 Reply
1 n keysyms-per-keycode
2 CARD16 sequence number
4 nm reply length (m = count field from the request)
4 CARD32 tag
20 unused
4nm LISTofKEYSYM keysyms
1 CARD8 opcode
1 22 lbx opcode
2 2 request length
4 FONTABLE font
-->
1 1 Reply
1 BOOL compression
2 CARD16 sequence number
4 L reply length
4 CARD32 tag
20 unused
All of the following is conditional:
12 CHARINFO min-bounds
4 unused
12 CHARINFO max-bounds
4 unused
2 CARD16 min-char-or-byte2
2 CARD16 max-char-or-byte2
2 CARD16 default-char
2 n number of FONTPROPs in properties
1 draw-direction
0 LeftToRight
1 RightToLeft
1 CARD8 min-byte1
1 CARD8 max-byte1
1 BOOL all-chars-exist
2 INT16 font-ascent
2 INT16 font-descent
4 m number of elements in char-infos
8n LISTofFONTPROP properties
and either
12m LISTofCHARINFO char-infos
or
m LISTofLBXCHARINFO char-infos
1 CARD8 opcode
1 23 lbx opcode
2 6 request length
4 WINDOW window
4 ATOM property
4 ATOM type
1 CARD8 format
1 mode
0 Replace
1 Preprend
2 Append
2 unused
4 CARD32 length of data in format units
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
-->
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 CARD32 tag
20 unused
1 CARD8 opcode
1 24 lbx opcode
2 7 request length
4 WINDOW window
4 ATOM property
4 ATOM type
0 AnyPropertyType
1 CARD8 delete
3 unused
4 CARD32 long-offset
4 CARD32 long-length
-->
1 1 Reply
1 CARD8 format
2 CARD16 sequence number
4 CARD32 reply length
4 ATOM type
0 None
4 CARD32 bytes-after
4 CARD32 length of value in format units
(= 0 for format = 0)
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
4 CARD32 tag
8 unused
1 CARD8 opcode
1 25 lbx opcode
2 3+(n+p)/4 request length
4 CARD32 tag
4 CARD32 length of data in bytes
n LISTofBYTE data
p unused, p=pad(n)
1 CARD8 opcode
1 26 lbx opcode
2 L request length
1 CARD8 source drawable cache entry
1 LBXGCANDDRAWENT cache entries
4 or 0 DRAWABLE optional source drawable
b LBXGCANDDRAWUPDATE optional gc and dest drawable
c LBXPINT16 src-x
d LBXPINT16 src-y
e LBXPINT16 dst-x
f LBXPINT16 dst-y
g LBXCARD16 width
h LBXCARD16 height
p unused, p=Lpad
1 CARD8 opcode
1 27 lbx opcode
2 L request length
4 CARD32 bit plane
1 CARD8 source drawable cache entry
1 LBXGCANDDRAWENT cache entries
4 or 0 DRAWABLE optional source drawable
b LBXGCANDDRAWUPDATE optional gc and dest drawable
c LBXPINT16 src-x
d LBXPINT16 src-y
e LBXPINT16 dst-x
f LBXPINT16 dst-y
g LBXCARD16 width
h LBXCARD16 height
p unused, p=Lpad
1 CARD8 opcode
1 28 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
n LISTofTEXTITEM8 items
p unused, p=Lpad
1 CARD8 opcode
1 29 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
2n LISTofTEXTITEM16 items
p unused, p=Lpad
1 CARD8 opcode
1 30 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
n STRING8 string
p unused, p=Lpad
1 CARD8 opcode
1 31 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
2n STRING16 string
p unused, p=Lpad
1 CARD8 opcode
1 32 lbx opcode
2 2+(n+p)/4 request length
4 n length of extension name
n STRING8 extension name
p unused, p=pad(n)
-->
1 1 Reply
1 n number of requests in the extension
2 CARD16 sequence number
4 0 or 2*(m + p) reply length, m = (n+7)/8
1 BOOL present
1 CARD8 major opcode
1 CARD8 first event
1 CARD8 first error
20 unused
m LISTofMASK optional reply-mask
p unused, p=pad(m)
m LISTofMASK optional event-mask
p unused, p=pad(m)
1 CARD8 opcode
1 33 lbx opcode
2 L request length
1 CARD8 compression method
1 LBXGCANDDRAWENT cache entries
a PIPACKED bit-packed
b LBXGCANDDRAWUPDATE optional gc and drawable
c LBXCARD16 width
d LBXCARD16 height
e LBXPINT16 x
f LBXPINT16 y
n LISTofBYTE compressed image data
p unused, p=Lpad
PIPACKED
1 #x80 | (format << 5) | ((depth -1) << 2)
PIPACKED
1 (depth -1) << 2)
1 (format << 5) | left-pad
1 CARD8 opcode
1 34 lbx opcode
2 6 request length
4 DRAWABLE drawable
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
4 CARD32 plane mask
1 CARD8 format
3 unused
-->
1 1 Reply
1 CARD8 depth
2 CARD16 sequence number
4 (n+p)/4 reply length
4 (m+p)/4 X reply length; if uncompressed, m=n
4 VISUALID visual
0 None
1 compression method
15 unused
n LISTofBYTE data
p unused, p=pad(n)
1 CARD8 opcode
1 35 lbx opcode
2 2 request length
4 CARD32 large request length
1 CARD8 opcode
1 36 lbx opcode
2 1+n request length
4n LISTofBYTE data
1 CARD8 opcode
1 37 lbx opcode
2 1 request length
1 CARD8 opcode
1 38 lbx opcode
2 1+(2+m+n+p)/4 request length
2 m num-atoms
n LISTofLONGSTR names
p pad p=Lpad
-->
1 1 Reply
1 unused
2 CARD16 sequence number
4 a reply length, a = MAX(m - 6, 0)
4*m LISTofATOM atoms
p pad p = MAX(0, 4*(6 - m))
LONGSTR
2 c string length
c STRING8 string
1 CARD8 opcode
1 39 lbx opcode
2 2 request length
4 CARD32 window id
-->
1 1 Reply
1 backing store
0 NotUseful
1 WhenMapped
2 Always
2 CARD16 sequence number
4 7 reply length
4 VISUALID visual id
2 class
1 InputOutput
2 InputOnly
1 BITGRAVITY bit gravity
1 WINGRAVITY window gravity
4 CARD32 backing bit planes
4 CARD32 backing pixel
1 BOOL save under
1 BOOL map installed
1 map state
0 Unmapped
1 Unviewable
2 Viewable
1 BOOL override
4 COLORMAP colormap
4 SETofEVENT all events mask
4 SETofEVENT your event mask
2 SETofDEVICEEVENT do not propagate mask
2 unused
4 WINDOW root
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border width
1 CARD8 depth
1 unused
1 CARD8 opcode
1 40 lbx opcode
2 2 request length
4 COLORMAP colormap
--> If smart-grab is true, the reply is as follows:
1 1 Reply
1 #x80 flags
2 CARD16 sequence number
4 0 reply length
24 unused
If smart-grab is false, the reply is as follows:
1 1 Reply
1 flags (set of)
#x40 auto-release
#x20 three-channels
#x10 two-byte-pixels
lower four bits specifies bits-per-pixel
2 CARD16 sequence number
4 L reply length
m CHAN or CHANNELS cells (CHAN if !three-channels)
p 0 pad(m)
CHANNELS
a CHAN red
1 5 next channel
b CHAN green
1 5 next channel
c CHAN blue
1 0 list end
CHAN
d LISTofLBXPIXEL
LBXPIXEL
e PIXELPRIVATE or
PIXELPRIVATERANGE or
PIXELALLOC or
PIXELALLOCRANGE
PIXELPRIVATE
1 1 pixel-private
f PIXEL pixel
PIXEL
f CARD8 or CARD16 (CARD8 if !two-byte-pixels)
PIXELPRIVATERANGE
1 2 pixel-private-range
f PIXEL fist-pixel
f PIXEL last-pixel
PIXELALLOC
1 3 pixel-private
f PIXEL pixel
g COLORSINGLE or COLORTRIPLE color (COLORSINGLE if three-channels)
COLORSINGLE
h CARD8 or CARD16 value (CARD8 if bits-per-rgb =< 7)
COLORTRIPLE
h COLORSINGLE red
h COLORSINGLE green
h COLORSINGLE blue
PIXELALLOCRANGE
1 4 pixel-private
f PIXEL first-pixel
f PIXEL last-pixel
j LISTofCOLORSINGLE or color (COLORSINGLE if three-channels)
LISTofCOLORTRIPLE
1 CARD8 opcode
1 41 lbx opcode
2 2 request length
4 COLORMAP cmap
1 CARD8 opcode
1 42 lbx opcode
2 5 request length
4 COLORMAP colormap
4 CARD32 pixel
2 CARD16 red
2 CARD16 green
2 CARD16 blue
2 unused
1 CARD8 opcode
1 43 lbx opcode
2 1 request length
-->
1 1 Reply
1 n unused
2 CARD16 sequence number
4 0 reply length
24 unused
1 base + 0 code
1 0 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
1 base + 0 code
1 1 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
1 base + 0 code
1 3 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
1 LbxTagTypeModmap
2 LbxTagTypeKeymap
3 LbxTagTypeProperty
4 LbxTagTypeFont
5 LbxTagTypeConnInfo
20 unused
1 base + 0 code
1 4 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
3 LbxTagTypeProperty
20 unused
1 base + 0 code
1 5 lbx type
2 CARD16 sequence number
4 CARD32 client
#xFFFFFFFF a client not managed by the proxy
24 unused
1 base + 0 code
1 6 lbx type
2 CARD16 sequence number
28 unused
1 base + 1 code
1 CARD8 delta-time
1 INT8 delta-x
1 INT8 delta-y
The description of this event is on page 28.
1 base + 0 code
1 7 lbx type
1 INT8 delta-x
1 INT8 delta-y
2 CARD16 delta-time
2 CARD16 delta-sequence
The description of this event is on page 28.
1 base + 0 code
1 8 lbx type
2 CARD16 sequence number
4 COLORMAP colormap
24 unused
1 base + 0 code
1 9 lbx type
2 CARD16 sequence number
4 COLORMAP colormap
4 PIXEL pixel start
4 PIXEL pixel end
16 unused
LBX reencodes X event representations into the following sizes, if squishing is enabled:
KeyOrButton 32
EnterOrLeave 32
Keymap 32
Expose 20
GraphicsExposure 24
NoExposure 12
VisibilityNotify 12
CreateNotify 24
DestroyNotify 12
UnmapNotify 16
MapNotify 16
MapRequest 12
Reparent 24
ConfigureNotify 28
ConfigureRequest 28
GravityNotify 16
ResizeRequest 12
Circulate 20
Property Notify 20
SelectionClear 20
SelectionRequest 28
SelectionNotify 24
Colormap Notify 16
MappingNotify 8
ClientMessage 32
Unknown 32
1 event_base + 0 event code
1 2 lbx type
2 1+(2+2n+p)/4 request length
1 n count of diffs
1 CARD8 cache index
2n LISTofDIFFITEM offsets and differences
p unused, p=pad(2n)