Low Bandwidth X Extension

X Consortium Standard

Donna Converse

Jim Fulton

David Lemke

Ralph Mor

Keith Packard

Ray Tice

Dale Tonogai

X Version 11, Release 7.7

Version 1.0

Copyright © 1996 X Consortium

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 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 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 CONNECTION
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 otherwise to promote the sale, use or other dealings in
this Software without prior written authorization from the X Consortium.

X Window System is a trademark of The OpenGroup.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Table of Contents

Introduction
Description
    Data Flow
    Tags
    Short-circuiting
    Graphics Re-encoding
    Motion events
    Event Squishing
    Master Client
    Multiplexing of Clients
    Swapping
    Delta cache
    Stream Compression
    Authentication Protocols
C Library Interfaces
    Application Library Interfaces
    Proxy Library Interfaces
Protocol
    Syntactic Conventions and Common Types
    Errors
    Requests
    Events
    Responses
Algorithm Naming
Encoding
    Errors
    Requests
    Events
    Re-encoding of X Events
    Responses

Introduction

Low Bandwidth X (LBX) is a network-transparent protocol for running X Window
System applications over transport channels whose bandwidth and latency are
significantly worse than that used in local area networks. It combines a
variety of caching and reencoding techniques to reduce the volume of data that
must be sent over the wire. It can be used with existing clients by placing a
proxy between the clients and server, so that the low bandwidth/high latency
communication occurs between the proxy and server.

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 implementation. 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".

Description

The design center for LBX is to use a proxy as an intermediary between the
client and server. The proxy reencodes and compresses requests, events, replies
and errors, as well as the resulting data stream. Additionally, the proxy can
cache information from the server to provide low-latency replies to clients.
This reply generation by the proxy is known as short-circuiting. A proxy can
handle multiple clients for a given server, but does not prevent clients from
connecting directly to the server. The design allows the proxy to multiplex
multiple clients into a single data stream to the server.

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 negotiable, and in some cases, the algorithm used by a given
method is negotiable as well. LBX also provides for negotiation of extensions
to LBX.

Data Flow

The LBX data stream goes through a number of layers:

 1. Client requests

 2. Read by LBX and potential byte-swapping

 3. Request-specific compression

 4. Potential byte swapping

 5. Multiplexing of client request streams

 6. Delta replacement

 7. Stream compression

Transport

 1. Stream decompression

 2. Delta substitution

 3. Demultiplexing of client request streams

 4. Potential byte swapping

 5. Reencoding

 6. Request processing

The reverse process occurs with X server replies, events, and errors.

Tags

Tags are used to support caching of large data items that are expected to be
queried multiple times. Such things as the keyboard map and font metrics are
often requested by multiple clients. Rather than send the data each time, the
first time the data is sent it includes a tag. The proxy saves this data, so
that subsequent requests can send only the tag to refer to that same data. The
different types of tags are used for connection information, keyboard maps,
modifier maps, fonts information and properties.

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 bearing 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.

Tag Substitution in Requests

Many substitution requests have a tag field, followed by fields marked
optional. For these requests, if the optional fields are present, the data in
them is stored in the indicated tag, unless the tag is 0. If the optional
fields are absent, the tag field indicates the tag that contains the data for
the "optional" fields.

Property Tags

Property data makes special use of tags. A common use of properties is for
inter-client communication. If both clients use the proxy, it is wasteful to
send the data to the server and then back, when the server may never need it. 
LbxChangeProperty request does the same work as the core ChangeProperty
request, but it does not send the data. The reply to this request contains a
tag id corresponding to the data. If the property information is used locally,
the server responds to LbxGetProperty with the tag, and the property data need
never be sent to the server. If the server does require the data, it can issue
an LbxQueryTag message. The proxy can also send the data on at any time if it
judges it appropriate (i.e., when the wire goes idle). Since the proxy owns the
property data, it must not invalidate the tag before sending the data back to
the server via an LbxTagData request.

Short-circuiting

Short-circuiting is used to handle constant data. This includes atoms, color
name/RGB mappings, and AllocColor calls. Atoms and color name/RGB mappings stay
constant for the life of the server. AllocColor replies are constant for each
colormap. Short-circuiting replaces round-trip requests with one-way requests,
and can sometimes use one in place of many.

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. 
LbxIncrementPixel 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.

Graphics Re-encoding

The LBX proxy attempts to reencode PolyPoint, PolyLine, PolySegment, 
PolyRectangle, PolyArc, FillPoly, PolyFillRectangle, PolyFillArc, CopyArea, 
CopyPlane, PolyText8, PolyText16, ImageText8, and ImageText16 requests. If the
request can be reencoded, it may be replaced by an equivalent LBX form of the
request. The requests are reencoded by attempting to reduce 2-byte coordinate,
length, width and angle fields to 1 byte. Where applicable, the coordinate mode
is also converted to Previous to improve the compressibility of the resulting
data. In image requests, the image data may also be compressed.

Motion events

To prevent clogging the wire with MotionNotify events, the server and proxy
work together to control the number of events on the wire. This is done with
the LbxAllowMotion request. The request adds an amount to an allowed motion
count in the server, which is kept on a per-proxy basis. Every motion notify
event sent to the proxy decrements the allowed motion counter. If the allowed
motion count is less than or equal to zero, motion events not required by the X
protocol definition are not sent to the proxy. The allowed motion counter has a
minimum value of -2^31.

Event Squishing

In the core protocol, all events are padded as needed to be 32 bytes long. The
LBX extension reduces traffic by removing padding at the end of events, and
implying the event length from its type. This is known as squishing.

Master Client

When the initial X connection between the proxy and the server is converted to
LBX mode, the proxy itself becomes the master client. New client requests and
some tag messages are sent in the context of the master client.

Multiplexing of Clients

The LBX proxy multiplexes the data streams of all its clients into one stream,
and then splits them apart again when they are received. The LbxSwitch message
is used to tell each end which client is using the wire at the time.

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 LbxListenToAll 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 carrying tagged data precedes replies that refer to
that tagged data.

Swapping

Swapping is handled as with any X extension, with one caveat. Since a proxy can
be supporting clients with different byte orders, and they all share the same
wire, the length fields of all messages between the server and proxy are
expressed in the proxy byte order. This prevents any problems with length
computation that may occur when clients are switched.

Delta cache

LBX takes advantage of the fact that an X message may be very similar to one
that has been previously sent. For example, a KeyPress event may differ from a
previous KeyPress event in just a few bytes. By sending just the bytes that
differ (or "deltas"), the number of bytes sent over the wire can be
substantially reduced. Delta compaction is used on requests being sent by the
proxy as well as on replies and events being sent by the server.

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 , LbxStartProxy , LbxSwitch , LbxNewClient , LbxAllowMotion , 
LbxDelta , LbxQueryExtension , 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.

Stream Compression

Before being passed down to the transport layer messages can be passed through
a general purpose data compressor. The choice of compression algorithm is
negotiated with See LbxStartProxy. The proxy and server are not required to
support any specific stream compressor. As an example, however, the X
Consortium implementation of a ZLIB based compressor is described below.

Note

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;

Authentication Protocols

The current version of LBX does not support multipass authentication protocols
for clients of the proxy. These authentication protocols return an Authenticate
message in response to a connection setup request, and require additional
authentication data from the client after the LbxNewClient request, and before
the reply to LbxNewClient . One example of such a protocol is
XC-QUERY-SECURITY-1.

C Library Interfaces

The C Library routines for LBX are in the Xext library. The prototypes are
located in a file named "XLbx.h".

Application Library Interfaces

In a proxy environment, applications do not need to call these routines to take
advantage of LBX. Clients can, however, obtain information about the LBX
extension to the server using this interface. Use of this routine may be
altered when connected through a proxy, as described in See C Library
Interfaces.

XLbxQueryVersion

To determine the version of LBX supported by the X server, call 
XLbxQueryVersion .

Bool XLbxQueryVersion(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.

Proxy Library Interfaces

The following interfaces are intended for use by the proxy.

XLbxQueryExtension

To determine the dynamically assigned codes for the extension, use the Xlib
function XQueryExtension or the LBX function XLbxQueryExtension .

Bool XLbxQueryExtension(Display * display, int * major_opcode_return, int *
first_event_return, int * first_error_return);

display             Specifies the connection to the X server.

major_opcode_return Returns the major opcode.

first_event_return  Returns the first event code.

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 values are undefined.

XLbxGetEventBase

To determine the base event type code, use the Xlib function XQueryExtension or
the LBX function XLbxGetEventBase.

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.

Protocol

Syntactic Conventions and Common Types

Please refer to the X Window System Protocol specification, as this document
uses the syntactic conventions established there and references types defined
there.

The following additional types are defined by this extension:


DIFFITEM
1      CARD8      offset
1      CARD8      diff


LBXANGLE: CARD8 or 2 BYTE
      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


LBXARC:
      [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.


LBXCARD16: CARD8 or 2 BYTE
      where:
      0x0000 <= in < 0x00F0      CARD8
      0x00F0 <= in < 0x10F0      out[0] = 0xF0 | ((in - 0xF0) >>
8)
            out[1] = in - 0xF0


LBXGCANDDRAWENT
[ gc-cache-index, drawable-cache-index: CARD4 ]


LBXGCANDDRAWUPDATE
      drawable: DRAWABLE      /* present only if
drawable-cache-index
 == 0 */
gc: GC]      /* present only if gc-cache-index == 0 */


LBXGCANDDRAWABLE
      cache-entries: LBXGCANDDRAWENT
      updates: LBXGCANDDRAWUPDATE


LBXINT16: INT8 or 2 BYTE
      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


LBXPINT16: CARD8 or 2 BYTE       /* for
usually positive numbers */
      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


LBXPOINT: [x, y: LBXINT16]
      Within a list of points, after the first rectangle, x and y are
relative to the corresponding fields of the prior point.


LBXRECTANGLE:
      [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.

MASK: CARD8

Errors

As with the X11 protocol, when a request terminates with an error, the request
has no side effects (that is, there is no partial execution).

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.

Requests

There is one request that is expected to be used only by the client: 
LbxQueryVersion

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: LbxStartProxy , LbxStopProxy , LbxNewClient , 
LbxSwitch , LbxCloseClient , LbxModifySequence , 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.

Requests Initiated by the Proxy or by the Client

LbxQueryVersion
=>;
majorVersion: CARD16
minorVersion: CARD16

This request returns the major and minor version numbers of the LBX protocol.

The encoding of this request is on See LbxQueryVersion.

Requests Initiated or Substituted by the Proxy

LbxQueryExtension
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 is identical to the QueryExtension request, with an additional
field, and two optional additional fields. When the client issues an 
QueryExtension request, the proxy will substitute an LbxQueryExtension request.

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. Otherwise, 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 significant bit corresponds to the first request, and the next bit
corresponds to the next request, and so on. Each element 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 See LbxQueryExtension.

Control Requests Initiated by the Proxy

LbxStartProxy
options : LISTofOPTION
=>
choices: LISTofCHOICE
Errors: LbxClient , Alloc
where:
OPTION [optcode: CARD8,
len: OPTLEN,
option: (See See StartProxy Options) ]
CHOICE [optcode: CARD8,
len: OPTLEN,
choice: (See See StartProxy Options) ]

Table 1. StartProxy Options

┌────────────┬──────────────────┬──────────────────┬─────────────────────┐
│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   │
└────────────┴──────────────────┴──────────────────┴─────────────────────┘


 
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]
 

This request negotiates LBX protocol options, and switches the proxy-server
connection from X11 protocol to LBX protocol.

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 See Delta cache 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 See Stream Compression.) Each algorithm has
a name that follows the naming conventions in See Algorithm Naming. 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 available 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 See
Algorithm Naming.

Pixmap compression is negotiated using the pixmap-comp option. The proxy sends
a list of available algorithms. 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 referring to this
algorithm, a mask of valid formats, and a list of valid depths. Algorithm names
follow the conventions in See Algorithm Naming.

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 See Tags, 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
contains 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 specific to that
extension. The extension name follows the conventions in See Algorithm Naming.
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 See LbxStartProxy.

LbxStopProxy
Errors: LbxClient

This request terminates the connection between the proxy and X server, and
terminates any clients connected through the proxy.

The encoding for this request is on See LbxStopProxy.

An LbxClient error is returned if the requesting client is not an LBX proxy.

LbxNewClient
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]

Errors: LbxClient, Alloc

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 LbxNewClient 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 
LbxClient 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 connection-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 connection 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 information 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 connection information for
the new connection.

If the change-type field is set to AppGroupDeltas , then connection-data is
sent using the CONDIFROOT 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 substituted 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 See The description of this request is on
page 13..

LbxCloseClient
client : CARD32
Errors: LbxClient

This requests the server to close down the connection represented by the
specified proxy’s client identifier. If the specified client wasn’t previously
registered with the server by a LbxNewClient request, the server will send the 
LbxClient error.

The encoding for this request is on See The description of this request is on
page 12..

LbxSwitch
client : CARD32
Errors: LbxClient

This request causes the X server to treat subsequent requests as being from a
connection to the X server represented by the specified client identifier.

If the client making the request is not the proxy, or if the client identifier
sent in the request was not previously sent in a LbxNewClient request, an 
LbxClient error is returned.

The encoding for this request is on See LbxSwitch.

LbxSync
=>

The sync request causes the server to send a reply when all requests before the
sync request have been processed.

The encoding for this client is on See LbxSync.

LbxModifySequence
adjust : CARD32
Errors: None

This request advances the sequence number of the virtual client connection by
the specified amount. The proxy sends the LbxModifySequence request to the
server when it replies to a client request without forwarding the client
request on to the X server.

The encoding for this client is on See The description of this request is on
page 13..

LbxAllowMotion
num : CARD32
Errors: None

This request controls the delivery of optional motion notify events, as
described in See Motion events. The num field specifies an increase in the
allowed number of motion notify events sent.

The encoding for this request is on See The description of this request is on
page 14..

LbxInvalidateTag
tag : CARD32

The LBX proxy sends this notification to the X server when it refuses to store
tagged data, or when it releases tagged data which was previously stored and
which was not invalidated by a notification from the X server.

The encoding for this request is on See LbxInvalidateTag.

LbxTagData
tag : CARD32
real-length : CARD32
data : LISTofBYTE

This request specifies the data associated with a previously assigned tag. It
is sent in two circumstances: in response to receiving a SendTagDataEvent , and
spontaneously, when the proxy must rely on the server to store data which was
not previously received from the server. The data is carried in the byte order
and structure as would have originally been sent in the core protocol request.

The encoding for this request is on See LbxTagData.

LbxGrabCmap
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

This request asks the server for control of allocating new colormap cells in
the specified colormap. The server grants control by replying to this request.
If no changes have occurred since the last time this proxy grabbed this
colormap, then the smart-grab field of the reply is set to true, and the
optional fields are not sent. Otherwise, the current contents of the colormap
are placed in the reply, as described later in this section.

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 Lbx ReleaseCmap
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 LbxIncrementPixel 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 COLORTRIPLE, which has fields for red, green and blue. A single
channel is used when the visual type is not DirectColor or TrueColor .

If three-channels is True, separate red, green and blue channel lists are
enclosed, for describing a DirectColor 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
corresponding 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 allocation. 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 COLORSINGLE 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 See LbxGrabCmap.

LbxReleaseCmap
cmap : Colormap

This request releases the specified grabbed colormap. If the cmap field does
not refer to a colormap, a BadColormap error is produced.

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 See LbxReleaseCmap.

LbxInternAtoms
count : CARD16
names: LISTofSTRING8
=>
atoms : LISTofATOM
Errors: Alloc

This request allows the proxy to intern a group of atoms in a single round
trip. The server will create any atoms that do not exist.

The encoding for this request is on See LbxInternAtoms.

Substitution Requests

LbxAllocColor
cmap : Colormap
pixel : CARD32
red , green , blue : CARD16

This request is sent by a proxy that has given colormap grabbed to allocate a
new read-only cell in the colormap. The proxy may substitute this request for
the core AllocColor and AllocNamedColor requests.

The pixel field identifies the colormap cell to allocate. The red , green , and
blue fields are the hardware specific 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 
LbxStartProxy .

For colormaps of static visual types, the LbxIncrementPixel request is used
instead of LBX AllocColor .

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 See LbxAllocColor.

LbxIncrementPixel
cmap : COLORMAP
pixel : CARD32
Errors: None

This request replaces the AllocColor request for read-only pixels currently
allocated for the current client. If the visual type of the colormap is of a
static type, this request may be used on currently unallocated pixels. The
colormap is not required to be grabbed to use this request.

The encoding for this request is on See The description of this request is on
page 14..

LbxDelta
count : CARD8
cache-index : CARD8
diffs : LISTofDIFFITEM

This request contains a minimal amount of information relative to a similar
prior request. The information is in the form of a difference comparison to a
prior request. The prior request is specified by an index to a cache,
independently maintained by both the proxy and the server.

The encoding for this request is on See The description of this request is on
page 18..

LbxGetModifierMapping
=>
keyspermod : CARD8
tag : CARD32
keycodes : LISTofKEYCODE /* optional */

This request is identical to the core GetModifierMapping request, with the
addition of a tag being returned in the reply. See See Tag Substitution in
Requests for a description of the tag field and optional fields.

The encoding for this request is on See LbxGetModifierMapping.

LbxGetKeyboardMapping
firstKeyCode : KEYCODE
count : CARD8
=>
keysperkeycode : CARD8
tag : CARD32
keysyms : LISTofKEYSYM /* optional */
Errors: Value

This request is identical to the X GetKeyboardMapping protocol request, with
the addition that a tag is returned in the reply. See See Tag Substitution in
Requests for a description of the tag field and optional fields.

The encoding for this request is on See LbxGetKeyboardMapping.

LbxGetWinAttrAndGeom
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

GetWindowAttributes and GetGeometry are frequently used together in the X
protocol. LbxGetWinAttrAndGeom allows the proxy to request the same information
in one round trip.

The encoding for this request is on See LbxGetWinAttrAndGeom.

LbxQueryFont
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

This request is used to replace the core QueryFont request and has identical
semantics.

See See Tag Substitution in Requests 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 character-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 See LbxQueryFont.

LbxChangeProperty
window : WINDOW
property : ATOM
type : ATOM
format : {0,8,16,32}
mode : {Replace, Prepend, Append}
nUnits : CARD32
=>
tag: CARD32

This request is sent to the server when the client sends an X ChangeProperty 
request through the proxy. The size of the data is sent with this request, but
not the property data itself. The server reply contains a tag identifier for
the data, which is stored in the proxy. The proxy must not discard this data
before it is sent to the server, or invalidated by the server. This means that
before issuing an LbxStopProxy request, or exiting, the proxy must send Lbx
TagData requests for these items. If the server loses the connection before the
information is sent back, the server should revert the property value to its
last known value, if possible.

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 See LbxChangeProperty.

LbxGetProperty
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

This request may be used by the proxy as a substitution for a core GetProperty
request. It allows tags to be used for property data that is unlikely to change
often in value, but is likely to be fetched by multiple clients.

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 LbxGetProperty 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 See LbxGetProperty.

LbxPolyPoint
gc-and-drawable: LBXGCANDDRAWABLE
points : LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyPoint request. Not all PolyPoint requests can be
represented as LbxPolyPoint requests.

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 See LbxPolyPoint.

LbxPolyLine
gc-and-drawable: LBXGCANDDRAWABLE
points : LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyLine request. Not all PolyLine requests can be
represented as LbxPolyline requests.

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 See The description of this request is on
page 21..

LbxPolySegment
gc-and-drawable: LBXGCANDDRAWABLE
segments : LISTofLBXSEGMENT
 
where:
LBXSEGEMENT; [x1, y1, x2, y2: LBXINT16]
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolySegment request. Not all PolySegment requests can
be represented as LbxPolySegment requests.

For segments other than the first segment of the request, [x1, y1] is relative
to [x1, y1] of the previous segment. For all segments, [x2, y2] is relative to
that segment’s [x1, y1].

The encoding for this request is on See LbxPolySegment.

LbxPolyRectangle
gc-and-drawable: LBXGCANDDRAWABLE
rectangles : LISTofLBXRECTANGLE
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyRectangle request. Not all PolyRectangle requests
can be represented as LbxPolyRectangle requests.

The encoding for this request is on See The description of this request is on
page 22..

LbxPolyArc
gc-and-drawable: LBXGCANDDRAWABLE
arcs : LISTofLBXARC
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyArc request. Not all PolyArc requests can be
represented as LbxPolyArc requests.

The encoding for this request is on See LbxPolyArc.

LbxPolyFillRectangle
gc-and-drawable: LBXGCANDDRAWABLE
rectangles : LISTofLBXRECTANGLE
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyFillRectangle request. Not all PolyFillRectangle
requests can be represented as LbxPolyFillRectangle requests.

The encoding for this request is on See LbxPolyFillRectangle.

LbxPolyFillArc
gc-and-drawable: LBXGCANDDRAWABLE
arcs : LISTofLBXARC
Errors: Alloc and those given for the corresponding X request.

This request replaces the PolyFillArc request. Not all PolyFillArc requests can
be represented as LbxPolyFillArc requests.

The encoding for this request is on See The description of this request is on
page 22..

LbxFillPoly
gc-and-drawable: LBXGCANDDRAWABLE
shape : BYTE
points : LISTofLBXPOINT
Errors: Alloc and those given for the corresponding X request.

This request replaces the FillPoly request. Not all FillPoly requests can be
represented as LbxFillPoly requests.

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 See LbxFillPoly.

LbxCopyArea
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.

This request replaces the CopyArea request for requests within its encoding
range.

The encoding for this request is on See LbxCopyArea.

LbxCopyPlane
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.

This request replaces the CopyPlane request for requests within its coding
range.

The encoding for this request is on See LbxCopyPlane.

LbxPolyText8
gc-and-drawable: LBXGCANDDRAWABLE
x : LBXPINT16
y : LBXPINT16
items : LISTofTEXTITEM8
Errors: Alloc , and those given for the corresponding X request.

This request replaces the PolyText8 request for requests within its encoding
range.

The encoding for this request is on See The description of this request is on
page 23..

LbxPolyText16
gc-and-drawable: LBXGCANDDRAWABLE
x: LBXPINT16
y : LBXPINT16
items : LISTofTEXTITEM16
Errors: Alloc , and those given for the corresponding X request.

This request replaces the PolyText16 request for requests within its encoding
range.

The encoding for this request is on See The description of this request is on
page 24..

LbxImageText8
gc-and-drawable: LBXGCANDDRAWABLE
nChars : CARD8
x : LBXPINT16
y : LBXPINT16
string : STRING8
Errors: Alloc , and those given for the corresponding X request.

This request replaces the ImageText8 request for requests within its encoding
range.

The encoding for this request is on See The description of this request is on
page 24..

LbxImageText16
nChars : CARD8
gc-and-drawable: LBXGCANDDRAWABLE
x: LBXPINT16
y : LBXPINT16
string : STRING16
Errors: Alloc , and those given for the corresponding X request.

This request replaces the ImageText16 request for requests within its encoding
range.

The encoding for this request is on See The description of this request is on
page 24..

LbxPutImage
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

When the request can be usefully compressed, this request replaces the PutImage
request. The compression-method parameter contains the opcode of a compression
method returned in the LbxStartProxy reply. The pad-bytes parameter gives the
number of unused pad bytes that follow the compressed image data. All other
parameters are as in the X request. If the specified compression method is not
recognized, the server returns a Value error.

The encoding for this request is on See LbxPutImage.

LbxGetImage
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

This request can replace the GetImage request. The same semantics apply, with
the following exceptions.

The compression-method field contains the opcode of the compression method used
in the reply. The compression 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 See LbxGetImage.

LbxBeginLargeRequest
large-request-length : CARD32
Errors: Alloc

This request, along with the Lbx LargeRequestData and Lbx EndLargeRequest
requests, is used to transport a large request in pieces. The smaller size of
the resulting requests allows smoother multiplexing of clients on a single low
bandwidth connection to the server. The resulting finer-grained multiplexing
improves responsiveness for the other clients.

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 See The description of this request is on
page 25..

LbxLargeRequestData
data : LISTofBYTE
Errors: Alloc

This request is used to carry the segments of a larger request, as described in
the definition of LbxBeginLargeRequest . The data must be carried in order,
starting with the request header, and each segment must be multiples of 4 bytes
long. If the LbxLargeRequestData is not preceded by a corresponding 
LbxBeginLargeRequest , a BadAlloc error is generated.

The encoding for this request is on See The description of this request is on
page 26..

LbxEndLargeRequest
Errors: Length, Alloc

As described in the definition of LbxBeginLargeRequest , LbxEndLargeRequest is
used to signal the end of a series of LargeRequestData requests. If the total
length of the data transported by the LbxLargeRequestData requests does not
match the large-request-length field of the preceding LbxBeginLargeRequest
request, then a Length error occurs. If the LbxEndLargeRequest is not preceded
by a corresponding LbxBeginLargeRequest , a BadAlloc error is generated. The
request is executed in order for that client as if it were the request after
the request preceding LbxEndLargeRequest .

The encoding for this request is on See LbxEndLargeRequest.

Events

LbxSwitchEvent
client : CARD32

Notify the proxy that the subsequent replies, events, and errors are relative
to the specified client.

The encoding for this event is on See LbxSwitchEvent.

LbxCloseEvent
client : CARD32

Notify the proxy that the specified client's connection to the server is
closed.

The encoding for this event is on See The description of this event is on page
27..

LbxInvalidateTagEvent
tag : CARD32
tag-type : {Modmap, Keymap, Property, Font, ConnInfo}

This message informs the proxy that the tag and the server data referenced by
the tag are obsolete, and should be discarded. The tag type may be one of the
following values: LbxTagTypeModmap , LbxTagTypeKeymap , LbxTagTypeProperty , 
LbxTagTypeFont , LbxTagTypeConnInfo .

The encoding for this event is on See LbxInvalidateTagEvent.

LbxSendTagDataEvent
tag : CARD32
tag-type : {Property}

The server sends this event to the proxy to request a copy of tagged data which
is being stored by the proxy. The request contains a tag which was previously
assigned to the data by the server. The proxy should respond to SendTagData by
sending a TagData request to the server. The tag type may be one of the
following values: LbxTagTypeProperty .

The encoding for this event is on See LbxSendTagDataEvent.

LbxListenToOne
client : CARD32 or 0xffffffff

When the server is grabbed, ListenToOne is sent to the proxy. As an X client,
the proxy itself is unaffected by grabs, in order that it may respond to
requests for data from the X server.

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 See The description of this event is on page
27..

LbxListenToAll

Notify the proxy that the server has been ungrabbed, and that the proxy may now
send all buffered client requests on to the server.

The encoding for this event is on See The description of this event is on page
27..

LbxQuickMotionDeltaEvent
deltaTime : CARD8
deltaX : INT8
deltaY : INT8

This event is used as a replacement for the MotionNotify event when possible.
The fields are used as deltas to the most recent MotionNotify event encoded as
a MotionNotify event, LbxQuickMotionDeltaEvent , or LbxMotionDeltaEvent . Not
every MotionNotify event can be encoded as a LbxQuickMotionDeltaEvent .

The encoding for this event is on See LbxQuickMotionDeltaEvent.

LbxMotionDeltaEvent
deltaX : INT8
deltaY : INT8
deltaTime : CARD16
deltaSequence : CARD16

This event is used as a replacement for the MotionNotify event when possible.
The fields are used as deltas to the most recent MotionNotify event encoded as
a MotionNotify event, LbxQuickMotionDeltaEvent , or LbxMotionDeltaEvent . Not
every MotionNotify event can be encoded as a LbxMotionDeltaEvent .

The encoding for this event is on See LbxMotionDeltaEvent.

LbxReleaseCmapEvent
colormap : Colormap

This event notifies the proxy that it must release the grab on this colormap
via the ReleaseCmap request. See LbxReleaseCmap

The encoding for this event is on See LbxReleaseCmapEvent.

LbxFreeCellsEvent
colormap : Colormap
pixelStart, pixelEnd : CARD32

The LbxFreeCells event is sent to a proxy that has a colormap grabbed to notify
the proxy that the reference count of the described cells were decremented to
zero by the server or another proxy. The reference count includes those by this
proxy. The proxy must update its copy of the colormap state accordingly if the
colormap is still grabbed, or if the proxy may in the future grab the colormap
using smart-grab mode. See LbxGrabCmap

The pixelStart and pixelEnd fields of the event denote a continuous range of
cells that were freed.

The encoding for this event is on See LbxFreeCellsEvent.

Responses

Responses are messages from the server to the proxy that not, strictly
speaking, events, replies or errors.

LbxDeltaResponse
count : CARD8
cache-index : CARD8
diffs : LISTofDIFFITEM

This response carries an event, reply, or error that has been encoded relative
to a message in the response delta cache. The cache-index field is the index
into the cache. Each entry in diffs provides a byte offset and replacement
value to use in reconstructing the response.

The encoding for this event is on See LbxDeltaResponse.

Algorithm Naming

To avoid potential clashes between different but similar algorithms for stream,
bitmap, and pixmap compression, the following naming scheme will be adhered to:

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 registry 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.

Encoding

The syntax and types used in the encoding are taken from the X protocol
encoding. Where LBX defines new types, they are defined earlier in this
document.

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

If the number of unused bytes is variable, the encode-form typically is:


p            unused, p=pad(E)

where E is some expression, and pad(E) is the number of bytes needed to round E
up to a multiple of four.

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 indicate 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

For cached GC and Drawables:


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

Errors

LbxClient
1      0          Error
1      CARD8      error-base + 0
2      CARD16     sequence number
4                 unused
2      CARD16     lbx opcode
1      CARD8      major opcode
21                unused

Requests

LbxQueryVersion
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

The description of this request is on See LbxQueryVersion.

LbxStartProxy
1      CARD8                      opcode
1      1                          lbx opcode
2      L                          request length
n      NLISTofOPTION-REQUEST      options
p                                 unused, p=pad(n)

OPTION-REQUEST
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

The encoding of the option field depends on the option-code. See See StartProxy
Options.

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 has two possible encodings, depending on the size of the value carried:

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

DELTAOPT
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

NAMEDOPT
f      STR             type-name
1      g+1             option-data-length
g      LISTofBYTE      option-data (option specific)

PIXMAPMETHOD
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)

CHOICE
1      CARD8                request-option-index
b      OPTLEN               reply-option-byte-length
c      DELTACHOICE or       choice
      INDEXEDCHOICE or
      NLISTofINDEXEDOPT or
      NLISTofPIXMAPCHOICE or
      BOOL or
      INDEXEDCHOICE

The encoding of the choice field depends on the option-code. See See StartProxy
Options.

DELTACHOICE
1      CARD8      preferred cache size
1      CARD8      preferred message length in 4-byte units

INDEXEDCHOICE
1      CARD8           index
d      LISTofBYTE      data

PIXMAPCHOICE
1      CARD8           index
1      CARD8           opcode
1      BITMASK         format mask
e      NLISTofCARD8    depths

The description of this request is on See LbxStartProxy.

LbxStopProxy
1      CARD8      opcode
1      2          lbx opcode
2      1          request length

The description of this request is on See LbxStopProxy.

LbxSwitch
1      CARD8      opcode
1      3          lbx opcode
2      2          request length
4      CARD32     client

The description of this request is on See LbxSwitch.

LbxNewClient
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

The remaining bytes depend on the value of change-type and length.

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

For app-group-deltas, the additional bytes have the following form, with a
length of (a = 1 + 4c):

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

The description of this request is on See LbxNewClient.

LbxCloseClient
1      CARD8      opcode
1      5          lbx opcode
2      2          request length
4      CARD32     client

The description of this request is on See LbxCloseClient.

LbxModifySequence
1      CARD8      opcode
1      6          lbx opcode
2      2          request length
4      CARD32     offset to sequence number

The description of this request is on See LbxModifySequence.

LbxAllowMotion
1      CARD8      opcode
1      7          lbx opcode
2      2          request length
4      CARD32     number of MotionNotify events

The description of this request is on See LbxAllowMotion.

LbxIncrementPixel
1      CARD8      opcode
1      8          lbx opcode
2      3          request length
4      COLORMAP   colormap
4      CARD32      pixel

The description of this request is on See LbxIncrementPixel.

LbxDelta
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)

The description of this request is on See LbxDelta.

LbxGetModifierMapping
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

The description of this request is on See LbxGetModifierMapping.

LbxInvalidateTag
1      CARD8      opcode
1      12         lbx opcode
2      2          request length
4      CARD32     tag

The description of this request is on See LbxInvalidateTag.

LbxPolyPoint
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

The description of this request is on See LbxPolyPoint.

LbxPolyLine
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

The description of this request is on See LbxPolyLine.

LbxPolySegment
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

The description of this request is on See LbxPolySegment.

LbxPolyRectangle
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)

The description of this request is on See LbxPolyRectangle.

LbxPolyArc
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

The description of this request is on See LbxPolyArc.

LbxFillPoly
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

The description of this request is on See LbxFillPoly.

LbxPolyFillRectangle
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

The description of this request is on See LbxPolyFillRectangle.

LbxPolyFillArc
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

The description of this request is on See LbxPolyFillArc.

LbxGetKeyboardMapping
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

The description of this request is on See LbxGetKeyboardMapping.

LbxQueryFont
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

The description of this request is on See LbxQueryFont.

LbxChangeProperty
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

The description of this request is on See LbxChangeProperty.

LbxGetProperty
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

The description of this request is on See LbxGetProperty.

LbxTagData
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)

The description of this request is on See LbxTagData.

LbxCopyArea
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

The description of this request is on See LbxCopyArea.

LbxCopyPlane
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

The description of this request is on See LbxCopyPlane.

LbxPolyText8
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

The description of this request is on See LbxPolyText8.

LbxPolyText16
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

The description of this request is on See LbxPolyText16.

LbxImageText8
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

The description of this request is on See LbxImageText8.

LbxImageText16
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

The description of this request is on See LbxImageText16.

LbxQueryExtension
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)

The description of this request is on See LbxQueryExtension.

LbxPutImage
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

If there is no left padding and the depth is less than or equal to nine,
PIPPACKED is encoded as follows:

PIPACKED
1      #x80 | (format << 5) | ((depth -1) << 2)

Otherwise PIPACKED is defined as:

PIPACKED
1      (depth -1) << 2)
1      (format << 5) | left-pad

The description of this request is on See LbxPutImage.

LbxGetImage
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)

The description of this request is on See LbxGetImage.

LbxBeginLargeRequest
1      CARD8      opcode
1      35      lbx opcode
2      2      request length
4      CARD32      large request length

The description of this request is on See LbxBeginLargeRequest.

LbxLargeRequestData
1      CARD8      opcode
1      36      lbx opcode
2      1+n      request length
4n      LISTofBYTE      data

The description of this request is on See LbxLargeRequestData.

LbxEndLargeRequest
1      CARD8      opcode
1      37      lbx opcode
2      1      request length

The description of this request is on See LbxEndLargeRequest.

LbxInternAtoms
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

The description of this request is on See LbxInternAtoms.

LbxGetWinAttrAndGeom
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

The description of this request is on See LbxGetWinAttrAndGeom.

LbxGrabCmap
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

The description of this request is on See LbxGrabCmap.

LbxReleaseCmap
1      CARD8      opcode
1      41      lbx opcode
2      2      request length
4      COLORMAP      cmap

The description of this request is on See LbxReleaseCmap.

LbxAllocColor
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

The description of this request is on See LbxAllocColor.

LbxSync
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

The description of this request is on See LbxSync.

Events

LbxSwitchEvent
1      base + 0      code
1      0      lbx type
2      CARD16      sequence number
4      CARD32      client
24            unused

The description of this event is on See LbxSwitchEvent.

LbxCloseEvent
1      base + 0      code
1      1      lbx type
2      CARD16      sequence number
4      CARD32      client
24            unused

The description of this event is on See LbxCloseEvent.

LbxInvalidateTagEvent
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

The description of this event is on See LbxInvalidateTagEvent.

LbxSendTagDataEvent
1      base + 0      code
1      4      lbx type
2      CARD16      sequence number
4      CARD32      tag
4            tag-type
3      LbxTagTypeProperty
20            unused

The description of this event is on See LbxSendTagDataEvent.

LbxListenToOne
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

The description of this event is on See LbxListenToOne.

LbxListenToAll
1      base + 0      code
1      6      lbx type
2      CARD16      sequence number
28            unused

The description of this event is on See LbxListenToAll.

LbxQuickMotionDeltaEvent
1      base + 1      code
1      CARD8      delta-time
1      INT8      delta-x
1      INT8      delta-y

This event is not padded to 32 bytes.

The description of this event is on See LbxQuickMotionDeltaEvent.

LbxMotionDeltaEvent
1      base + 0      code
1      7                  lbx type
1      INT8      delta-x
1      INT8      delta-y
2      CARD16      delta-time
2      CARD16      delta-sequence

This event is not padded to 32 bytes.

The description of this event is on See LbxMotionDeltaEvent.

LbxReleaseCmapEvent
1      base + 0      code
1      8                  lbx type
2      CARD16      sequence number
4      COLORMAP      colormap
24            unused

The description of this event is on See LbxReleaseCmapEvent.

LbxFreeCellsEvent
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

The description of this event is on See LbxFreeCellsEvent.

Re-encoding of X Events

The X protocol requires all X events to be 32 bytes. The LBX server reduces the
number of bytes sent between the server and the proxy for some X events by not
appending unused pad bytes to the event data. The offsets of X event data are
unchanged. The proxy will pad the events to 32 bytes before passing them on to
the client.

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

Responses

LbxDeltaResponse
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)

The description of this response is on See LbxDeltaResponse.

