-=[ Mr. Bumblebee ]=-
_Indonesia_
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Low Bandwidth X Extension</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /><style xmlns="" type="text/css">/*
* Copyright (c) 2011 Gaetan Nadon
* Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
/*
* Shared stylesheet for X.Org documentation translated to HTML format
* http://www.sagehill.net/docbookxsl/UsingCSS.html
* http://www.w3schools.com/css/default.asp
* https://addons.mozilla.org/en-US/firefox/addon/web-developer/developers
* https://addons.mozilla.org/en-US/firefox/addon/font-finder/
*/
/*
* The sans-serif fonts are considered more legible on a computer screen
* http://dry.sailingissues.com/linux-equivalents-verdana-arial.html
*
*/
body {
font-family: "Bitstream Vera Sans", "DejaVu Sans", Tahoma, Geneva, Arial, Sans-serif;
/* In support of using "em" font size unit, the w3c recommended method */
font-size: 100%;
}
/*
* Selection: all elements requiring mono spaced fonts.
*
* The family names attempt to match the proportionally spaced font
* family names such that the same font name is used for both.
* We'd like to use Bitstream, for example, in both proportionally and
* mono spaced font text.
*/
.command,
.errorcode,
.errorname,
.errortype,
.filename,
.funcsynopsis,
.function,
.parameter,
.programlisting,
.property,
.screen,
.structname,
.symbol,
.synopsis,
.type
{
font-family: "Bitstream Vera Sans Mono", "DejaVu Sans Mono", Courier, "Liberation Mono", Monospace;
}
/*
* Books have a title page, a preface, some chapters and appendices,
* a glossary, an index and a bibliography, in that order.
*
* An Article has no preface and no chapters. It has sections, appendices,
* a glossary, an index and a bibliography.
*/
/*
* Selection: book main title and subtitle
*/
div.book>div.titlepage h1.title,
div.book>div.titlepage h2.subtitle {
text-align: center;
}
/*
* Selection: article main title and subtitle
*/
div.article>div.titlepage h2.title,
div.article>div.titlepage h3.subtitle,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title {
text-align: center;
}
/*
* Selection: various types of authors and collaborators, individuals or corporate
*
* These authors are not always contained inside an authorgroup.
* They can be contained inside a lot of different parent types where they might
* not be centered.
* Reducing the margin at the bottom makes a visual separation between authors
* We specify here the ones on the title page, others may be added based on merit.
*/
div.titlepage .authorgroup,
div.titlepage .author,
div.titlepage .collab,
div.titlepage .corpauthor,
div.titlepage .corpcredit,
div.titlepage .editor,
div.titlepage .othercredit {
text-align: center;
margin-bottom: 0.25em;
}
/*
* Selection: the affiliation of various types of authors and collaborators,
* individuals or corporate.
*/
div.titlepage .affiliation {
text-align: center;
}
/*
* Selection: product release information (X Version 11, Release 7)
*
* The releaseinfo element can be contained inside a lot of different parent
* types where it might not be centered.
* We specify here the one on the title page, others may be added based on merit.
*/
div.titlepage p.releaseinfo {
font-weight: bold;
text-align: center;
}
/*
* Selection: publishing date
*/
div.titlepage .pubdate {
text-align: center;
}
/*
* The legal notices are displayed in smaller sized fonts
* Justification is only supported in IE and therefore not requested.
*
*/
.legalnotice {
font-size: small;
font-style: italic;
}
/*
* For documentation having multiple licenses, the copyright and legalnotice
* elements sequence cannot instantiated multiple times.
* The copyright notice and license text are therefore coded inside a legalnotice
* element. The role attribute on the paragraph is used to allow styling of the
* copyright notice text which should not be italicized.
*/
p.multiLicensing {
font-style: normal;
font-size: medium;
}
/*
* Selection: book or article main ToC title
* A paragraph is generated for the title rather than a level 2 heading.
* We do not want to select chapters sub table of contents, only the main one
*/
div.book>div.toc>p,
div.article>div.toc>p {
font-size: 1.5em;
text-align: center;
}
/*
* Selection: major sections of a book or an article
*
* Unlike books, articles do not have a titlepage element for appendix.
* Using the selector "div.titlepage h2.title" would be too general.
*/
div.book>div.preface>div.titlepage h2.title,
div.book>div.chapter>div.titlepage h2.title,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title,
div.book>div.appendix>div.titlepage h2.title,
div.article>div.appendix h2.title,
div.glossary>div.titlepage h2.title,
div.index>div.titlepage h2.title,
div.bibliography>div.titlepage h2.title {
/* Add a border top over the major parts, just like printed books */
/* The Gray color is already used for the ruler over the main ToC. */
border-top-style: solid;
border-top-width: 2px;
border-top-color: Gray;
/* Put some space between the border and the title */
padding-top: 0.2em;
text-align: center;
}
/*
* A Screen is a verbatim environment for displaying text that the user might
* see on a computer terminal. It is often used to display the results of a command.
*
* http://www.css3.info/preview/rounded-border/
*/
.screen {
background: #e0ffff;
border-width: 1px;
border-style: solid;
border-color: #B0C4DE;
border-radius: 1.0em;
/* Browser's vendor properties prior to CSS 3 */
-moz-border-radius: 1.0em;
-webkit-border-radius: 1.0em;
-khtml-border-radius: 1.0em;
margin-left: 1.0em;
margin-right: 1.0em;
padding: 0.5em;
}
/*
* Emphasis program listings with a light shade of gray similar to what
* DocBook XSL guide does: http://www.sagehill.net/docbookxsl/ProgramListings.html
* Found many C API docs on the web using like shades of gray.
*/
.programlisting {
background: #F4F4F4;
border-width: 1px;
border-style: solid;
border-color: Gray;
padding: 0.5em;
}
/*
* Emphasis functions synopsis using a darker shade of gray.
* Add a border such that it stands out more.
* Set the padding so the text does not touch the border.
*/
.funcsynopsis, .synopsis {
background: #e6e6fa;
border-width: 1px;
border-style: solid;
border-color: Gray;
clear: both;
margin: 0.5em;
padding: 0.25em;
}
/*
* Selection: paragraphs inside synopsis
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in synopsis
*/
.funcsynopsis p,
.synopsis p {
margin: 0;
padding: 0;
}
/*
* Selection: variable lists, informal tables and tables
*
* Note the parameter name "variablelist.as.table" in xorg-xhtml.xsl
* A table with rows and columns is constructed inside div.variablelist
*
* Set the left margin so it is indented to the right
* Display informal tables with single line borders
*/
table {
margin-left: 0.5em;
border-collapse: collapse;
}
/*
* Selection: paragraphs inside tables
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in tables
*/
td p {
margin: 0;
padding: 0;
}
/*
* Add some space between the left and right column.
* The vertical alignment helps the reader associate a term
* with a multi-line definition.
*/
td, th {
padding-left: 1.0em;
padding-right: 1.0em;
vertical-align: top;
}
.warning {
border: 1px solid red;
background: #FFFF66;
padding-left: 0.5em;
}
</style></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="lbx"></a>Low Bandwidth X Extension</h2></div><div><h3 class="subtitle"><em>X Consortium Standard</em></h3></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Donna</span> <span class="surname">Converse</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Jim</span> <span class="surname">Fulton</span></h3></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="surname">Lemke</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Ralph</span> <span class="surname">Mor</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Keith</span> <span class="surname">Packard</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Ray</span> <span class="surname">Tice</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Dale</span> <span class="surname">Tonogai</span></h3></div></div></div><div><p class="releaseinfo">X Version 11, Release 7.7</p></div><div><p class="releaseinfo">Version 1.0</p></div><div><p class="copyright">Copyright © 1996 X Consortium</p></div><div><div class="legalnotice"><a id="idp50375296"></a><p>
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:
</p><p>
The above copyright notice and this permission notice shall be included in all
copies or substantial portions
of the Software.
</p><p>
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.
</p><p>
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.
</p><p>X Window System is a trademark of The OpenGroup.</p></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#introduction">Introduction</a></span></dt><dt><span class="sect1"><a href="#description">Description</a></span></dt><dd><dl><dt><span class="sect2"><a href="#data_flow">Data Flow</a></span></dt><dt><span class="sect2"><a href="#tags">Tags</a></span></dt><dt><span class="sect2"><a href="#short_circuiting">Short-circuiting</a></span></dt><dt><span class="sect2"><a href="#graphics_re_encoding">Graphics Re-encoding</a></span></dt><dt><span class="sect2"><a href="#motion_events">Motion events</a></span></dt><dt><span class="sect2"><a href="#event_squishing">Event Squishing</a></span></dt><dt><span class="sect2"><a href="#master_client_">Master Client </a></span></dt><dt><span class="sect2"><a href="#multiplexing_of_clients">Multiplexing of Clients</a></span></dt><dt><span class="sect2"><a href="#swapping">Swapping</a></span></dt><dt><span class="sect2"><a href="#delta_cache">Delta cache</a></span></dt><dt><span class="sect2"><a href="#stream_compression">Stream Compression</a></span></dt><dt><span class="sect2"><a href="#authentication_protocols">Authentication Protocols</a></span></dt></dl></dd><dt><span class="sect1"><a href="#c_library_interfaces_">C Library Interfaces </a></span></dt><dd><dl><dt><span class="sect2"><a href="#application_library_interfaces">Application Library Interfaces</a></span></dt><dt><span class="sect2"><a href="#proxy_library_interfaces">Proxy Library Interfaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="#protocol">Protocol</a></span></dt><dd><dl><dt><span class="sect2"><a href="#syntactic_conventions_and_common_types">Syntactic Conventions and Common Types</a></span></dt><dt><span class="sect2"><a href="#errors">Errors</a></span></dt><dt><span class="sect2"><a href="#requests">Requests</a></span></dt><dt><span class="sect2"><a href="#events">Events</a></span></dt><dt><span class="sect2"><a href="#responses">Responses</a></span></dt></dl></dd><dt><span class="sect1"><a href="#algorithm_naming">Algorithm Naming</a></span></dt><dt><span class="sect1"><a href="#encoding">Encoding</a></span></dt><dd><dl><dt><span class="sect2"><a href="#errors2">Errors</a></span></dt><dt><span class="sect2"><a href="#requests2">Requests</a></span></dt><dt><span class="sect2"><a href="#events2">Events</a></span></dt><dt><span class="sect2"><a href="#re_encoding_of_x_events">Re-encoding of X Events</a></span></dt><dt><span class="sect2"><a href="#responses2">Responses</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="introduction"></a>Introduction</h2></div></div></div><p>
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.
</p><p>
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.
</p><p>
The extension name is "LBX".
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="description"></a>Description</h2></div></div></div><p>
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.
</p><p>
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.
</p><p>
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.
</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="data_flow"></a>Data Flow</h3></div></div></div><p>
The LBX data stream goes through a number of layers:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Client requests</p></li><li class="listitem"><p>Read by LBX and potential byte-swapping</p></li><li class="listitem"><p>Request-specific compression</p></li><li class="listitem"><p>Potential byte swapping</p></li><li class="listitem"><p>Multiplexing of client request streams</p></li><li class="listitem"><p>Delta replacement</p></li><li class="listitem"><p>Stream compression</p></li></ol></div><p>
Transport
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Stream decompression</p></li><li class="listitem"><p>Delta substitution</p></li><li class="listitem"><p>Demultiplexing of client request streams</p></li><li class="listitem"><p>Potential byte swapping</p></li><li class="listitem"><p>Reencoding</p></li><li class="listitem"><p>Request processing</p></li></ol></div><p>
The reverse process occurs with X server replies, events, and errors.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="tags"></a>Tags</h3></div></div></div><p>
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.
</p><p>
Tag usage is negotiated as a boolean in the <span class="emphasis"><em>
LbxStartProxy</em></span>
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.
</p><p>
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 <span class="emphasis"><em>
LbxInvalidateTag</em></span>
message to release the tagged data. The proxy must not invalidate connection
tags unless instructed to do so by the server.
</p><p>
If the server wishes to discard tagged data, it must either have received an
<span class="emphasis"><em>
LbxInvalidateTag</em></span>
request from the proxy or send an <span class="emphasis"><em>
LbxInvalidateTag</em></span>
event to the proxy for that tag.
</p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="tag_substitution_in_requests"></a>Tag Substitution in Requests</h4></div></div></div><p>
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.
</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="property_tags"></a>Property Tags</h4></div></div></div><p>
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.
<span class="emphasis"><em>
LbxChangeProperty</em></span>
request does the same work as the core <span class="emphasis"><em>
ChangeProperty</em></span>
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 <span class="emphasis"><em>
LbxGetProperty</em></span>
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 <span class="emphasis"><em>
LbxQueryTag</em></span>
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 <span class="emphasis"><em>
LbxTagData</em></span>
request.
</p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="short_circuiting"></a>Short-circuiting</h3></div></div></div><p>
Short-circuiting is used to handle constant data. This includes atoms, color
name/RGB mappings, and <span class="emphasis"><em>
AllocColor</em></span>
calls. Atoms and color name/RGB mappings stay constant for the life of the
server. <span class="emphasis"><em>
AllocColor</em></span>
<span class="emphasis"><em>
</em></span>
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.
</p><p>
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.
</p><p>
Colorname/RGB mappings are constant, so once the proxy sees the response from
<span class="emphasis"><em>
LookupColor</em></span>
, it need not forward any subsequent requests.
</p><p>
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 <span class="emphasis"><em>
AllocColor</em></span>
requests it can resolve, but it must tell the server to modify the color
cell's reference count. <span class="emphasis"><em>
LbxIncrementPixel</em></span>
is used to support this.
</p><p>
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 <span class="emphasis"><em>
LbxModifySequence</em></span>
.
</p><p>
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.
</p><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="graphics_re_encoding"></a>Graphics Re-encoding</h3></div></div></div><p>
The LBX proxy attempts to reencode <span class="emphasis"><em>PolyPoint</em></span>,
<span class="emphasis"><em>PolyLine</em></span>, <span class="emphasis"><em>PolySegment</em></span>,
<span class="emphasis"><em>PolyRectangle</em></span>, <span class="emphasis"><em>PolyArc</em></span>,
<span class="emphasis"><em>FillPoly</em></span>, <span class="emphasis"><em>PolyFillRectangle</em></span>,
<span class="emphasis"><em>PolyFillArc</em></span>, <span class="emphasis"><em>CopyArea</em></span>,
<span class="emphasis"><em>CopyPlane</em></span>, <span class="emphasis"><em>PolyText8</em></span>,
<span class="emphasis"><em>PolyText16</em></span>, <span class="emphasis"><em>ImageText8</em></span>,
and <span class="emphasis"><em>ImageText16</em></span> 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 <span class="emphasis"><em>Previous</em></span>
to improve the compressibility of the resulting data. In image requests,
the image data may also be compressed.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="motion_events"></a>Motion events</h3></div></div></div><p>
To prevent clogging the wire with <span class="emphasis"><em>MotionNotify</em></span>
events, the server and proxy work together to control the number
of events on the wire. This is done with the
<span class="emphasis"><em>LbxAllowMotion</em></span>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="event_squishing"></a>Event Squishing</h3></div></div></div><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="master_client_"></a>Master Client </h3></div></div></div><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="multiplexing_of_clients"></a>Multiplexing of Clients</h3></div></div></div><p>
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 <span class="emphasis"><em>
LbxSwitch</em></span>
message is used to tell each end which client is using the wire at the time.
</p><p>
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.
</p><p>
The server can affect the multiplexing of clients by the proxy using the
<span class="emphasis"><em>
LbxListenToOne</em></span>
and <span class="emphasis"><em>
LbxListenToAll</em></span>
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.
</p><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="swapping"></a>Swapping</h3></div></div></div><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="delta_cache"></a>Delta cache</h3></div></div></div><p>
LBX takes advantage of the fact that an X message may be very similar to one
that has been previously sent. For example, a <span class="emphasis"><em>
KeyPress</em></span>
event may differ from a previous <span class="emphasis"><em>
KeyPress</em></span>
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.
</p><p>
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 <span class="emphasis"><em>
LbxStartProxy</em></span>
request.
</p><p>
The LBX requests that are never stored in the request delta cache are the
<span class="emphasis"><em>
LbxQueryVersion</em></span>
, <span class="emphasis"><em>
LbxStartProxy</em></span>
, <span class="emphasis"><em>
LbxSwitch</em></span>
, <span class="emphasis"><em>
LbxNewClient</em></span>
, <span class="emphasis"><em>
LbxAllowMotion</em></span>
, <span class="emphasis"><em>
LbxDelta</em></span>
, <span class="emphasis"><em>
LbxQueryExtension</em></span>
, <span class="emphasis"><em>
LbxPutImage</em></span>
, <span class="emphasis"><em>
LbxGetImage</em></span>
, <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
, <span class="emphasis"><em>
LbxLargeRequestData</em></span>
, <span class="emphasis"><em>
LbxEndLargeRequest</em></span>
and <span class="emphasis"><em>
LbxInternAtoms</em></span>
requests. The responses that are never stored in the response cache are
<span class="emphasis"><em>
LbxSwitchEvent</em></span>
and <span class="emphasis"><em>
LbxDeltaResponse</em></span>
. The message carried by a <span class="emphasis"><em>
delta </em></span>
message is also cached, if it meets the other requirements. Messages after the
<span class="emphasis"><em>
LbxStartProxy</em></span>
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.
</p><p>
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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="stream_compression"></a>Stream Compression</h3></div></div></div><p>
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 <a class="ulink" href="lbx.htm#20870" target="_top">See LbxStartProxy</a>. 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.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
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:
</p></div><pre class="programlisting">
out[0] = (length & 0xfff) >> 8 | ((compflag) ? 0x80 : 0);
out[1] = length & 0xff;
</pre></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="authentication_protocols"></a>Authentication Protocols</h3></div></div></div><p>
The current version of LBX does not support multipass authentication protocols
for clients of the proxy. These authentication protocols return an <span class="emphasis"><em>
Authenticate</em></span>
message in response to a connection setup request, and require additional
authentication data from the client after the <span class="emphasis"><em>
LbxNewClient</em></span>
request, and before the reply to <span class="emphasis"><em>
LbxNewClient</em></span>
. One example of such a protocol is XC-QUERY-SECURITY-1.
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="c_library_interfaces_"></a>C Library Interfaces </h2></div></div></div><p>
The C Library routines for LBX are in the Xext library. The prototypes are
located in a file named "XLbx.h".
</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="application_library_interfaces"></a>Application Library Interfaces</h3></div></div></div><p>
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 <a class="ulink" href="lbx.htm#33319" target="_top">See C Library Interfaces</a>.
</p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="xlbxqueryversion"></a>XLbxQueryVersion</h4></div></div></div><p>
To determine the version of LBX supported by the X server, call <span class="emphasis"><em>
XLbxQueryVersion</em></span>
.
</p><div class="funcsynopsis"><p><code class="funcdef">Bool <strong class="fsfunc">XLbxQueryVersion</strong>(</code>Display * <var class="pdparam">display</var>, int * <var class="pdparam">major_version_return</var>, int * <var class="pdparam">minor_version_return</var><code>)</code>;</p></div><div class="variablelist"><table border="0" class="variablelist"><colgroup><col align="left" valign="top" /><col /></colgroup><tbody><tr><td><p><span class="term">display</span></p></td><td><p>Specifies the connection to the X server.</p></td></tr><tr><td><p><span class="term">major_version_return</span></p></td><td><p>Returns the extension major version number.</p></td></tr><tr><td><p><span class="term">minor_version_return</span></p></td><td><p>Returns the extension minor version number.</p></td></tr></tbody></table></div><p>
The <span class="emphasis"><em>
XLbxQueryVersion</em></span>
function determines if the LBX extension is present. If the extension is not
present, <span class="emphasis"><em>
XLbxQueryVersion</em></span>
returns <span class="emphasis"><em>
False</em></span>
; otherwise, it returns <span class="emphasis"><em>
True</em></span>
. If the extension is present, <span class="emphasis"><em>
XLbxQueryVersion</em></span>
returns the major and minor version numbers of the extension as supported by
the X server.
</p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="proxy_library_interfaces"></a>Proxy Library Interfaces</h3></div></div></div><p>
The following interfaces are intended for use by the proxy.
</p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="xlbxqueryextension"></a>XLbxQueryExtension</h4></div></div></div><p>
To determine the dynamically assigned codes for the extension, use the Xlib
function <span class="emphasis"><em>
XQueryExtension</em></span>
or the LBX function <span class="emphasis"><em>
XLbxQueryExtension</em></span>
.</p><div class="funcsynopsis"><p><code class="funcdef">Bool <strong class="fsfunc">XLbxQueryExtension</strong>(</code>Display * <var class="pdparam">display</var>, int * <var class="pdparam">major_opcode_return</var>, int * <var class="pdparam">first_event_return</var>, int * <var class="pdparam">first_error_return</var><code>)</code>;</p></div><div class="variablelist"><table border="0" class="variablelist"><colgroup><col align="left" valign="top" /><col /></colgroup><tbody><tr><td><p><span class="term">display</span></p></td><td><p>Specifies the connection to the X server.</p></td></tr><tr><td><p><span class="term">major_opcode_return</span></p></td><td><p>Returns the major opcode.</p></td></tr><tr><td><p><span class="term">first_event_return</span></p></td><td><p>Returns the first event code.</p></td></tr><tr><td><p><span class="term">first_error_return</span></p></td><td><p>Returns the first error code.</p></td></tr></tbody></table></div><p>
The <span class="emphasis"><em>
XLbxQueryExtension</em></span>
function determines if the LBX extension is present. If the extension is not
present, <span class="emphasis"><em>
XLbxQueryExtension</em></span>
returns <span class="emphasis"><em>
False</em></span>
; otherwise, it returns <span class="emphasis"><em>
True</em></span>
. If the extension is present, <span class="emphasis"><em>
XLbxQueryExtension</em></span>
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.
</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="xlbxgeteventbase"></a>XLbxGetEventBase</h4></div></div></div><p>
To determine the base event type code, use the Xlib function <span class="emphasis"><em>
XQueryExtension</em></span>
or the LBX function <span class="emphasis"><em>
XLbxGetEventBase</em></span>.
</p><div class="funcsynopsis"><p><code class="funcdef">int <strong class="fsfunc">XLbxGetEventBase</strong>(</code>Display * <var class="pdparam">display</var><code>)</code>;</p></div><div class="variablelist"><table border="0" class="variablelist"><colgroup><col align="left" valign="top" /><col /></colgroup><tbody><tr><td><p><span class="term">display</span></p></td><td><p>Specifies the connection to the X server.</p></td></tr></tbody></table></div><p>
The <span class="emphasis"><em>XLbxGetEventBase</em></span>
function returns the base event type code if the extension is
present; otherwise, it returns -1.
</p></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="protocol"></a>Protocol</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="syntactic_conventions_and_common_types"></a>Syntactic Conventions and Common Types</h3></div></div></div><p>
Please refer to the X Window System Protocol specification,
as this document uses the syntactic conventions established
there and references types defined there.
</p><p>
The following additional types are defined by this extension:
</p><div class="literallayout"><p><br />
<span class="bold"><strong>DIFFITEM</strong></span><br />
1 CARD8 offset<br />
1 CARD8 diff<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXANGLE: CARD8 or 2 BYTE</strong></span><br />
where (in order of precedence):<br />
(0 <= in <= A(95)) && !(in % A(5)) out = 0x5a + (in /<br />
A(5))<br />
A(105) <= in <= A(360) && !(in % A(15)) out = 0x67 +<br />
(in / A(15))<br />
-A(100) <= in <= -A(5) && !(in % A(5)) out = 0xa6 +<br />
(in / A(5))<br />
-A(360) < in <= -A(105) && !(in % A(15)) out = 0x98 +<br />
(in / A(15))<br />
-A(360) < in <= A(360) out[0] = in >> 8; out[1] = in<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXARC:</strong></span><br />
[x, y: LBXINT16,<br />
width, height: LBXCARD16,<br />
angle1, angle2: LBXANGLE]<br />
</p></div><p>
Within a list of arcs, after the first arc, x and y are
relative to the corresponding fields of the prior arc.
</p><div class="literallayout"><p><br />
<span class="bold"><strong>LBXCARD16: CARD8 or 2 BYTE</strong></span><br />
where:<br />
0x0000 <= in < 0x00F0 CARD8<br />
0x00F0 <= in < 0x10F0 out[0] = 0xF0 | ((in - 0xF0) >><br />
8)<br />
out[1] = in - 0xF0<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXGCANDDRAWENT</strong></span><br />
[ gc-cache-index, drawable-cache-index: CARD4 ]<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXGCANDDRAWUPDATE</strong></span><br />
drawable: DRAWABLE /* present only if<br />
<span class="emphasis"><em>drawable-cache-index</em></span><br />
== 0 */<br />
gc: GC] /* present only if <span class="emphasis"><em>gc-cache-index</em></span> == 0 */<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXGCANDDRAWABLE</strong></span><br />
cache-entries: LBXGCANDDRAWENT<br />
updates: LBXGCANDDRAWUPDATE<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXINT16</strong></span>: INT8 or 2 BYTE<br />
where:<br />
0xF790 <= in < 0xFF90 out[0] = 0x80 | (((in + 0x70) >><br />
8) & 0x0F)<br />
out[1] = in + 0x70<br />
0xFF90 <= in < 0x0080 CARD8<br />
0x0080 <= in < 0x0880 out[0] = 0x80 | (((in - 0x80) >><br />
8) & 0x0F)<br />
out[1] = in - 0x80<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXPINT16</strong></span>: CARD8 or 2 BYTE /* for<br />
usually positive numbers */<br />
where:<br />
0xFE00 <= in < 0x0000 out[0] = 0xF0 | (((in + 0x1000)<br />
>> 8) & 0x0F)<br />
out[1] = in + 0x1000<br />
0x0000 <= in < 0x00F0 CARD8<br />
0x00F0 <= in < 0x0EF0 out[0] = 0xF0 | ((in - 0xF0) >>8)<br />
out[1] = in - 0xF0<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXPOINT</strong></span>: [x, y: LBXINT16]<br />
Within a list of points, after the first rectangle, x and y are<br />
relative to the corresponding fields of the prior point.<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXRECTANGLE</strong></span>:<br />
[x, y: LBXINT16,<br />
width, height: LBXCARD16]<br />
</p></div><p>
Within a list of rectangles, after the first rectangle, x and
y are relative to the corresponding fields of the prior rectangle.
</p><p>
MASK: CARD8
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="errors"></a>Errors</h3></div></div></div><p>
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).
</p><p>
There is one error, <span class="emphasis"><em>
LbxClient</em></span>
. 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.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="requests"></a>Requests</h3></div></div></div><p>
There is one request that is expected to be used only by the client: <span class="emphasis"><em>
LbxQueryVersion</em></span>
</p><p>
There is one request that is expected to be used by the client or the proxy:
<span class="emphasis"><em>
LbxQueryExtension</em></span>
.
</p><p>
The following requests are expected to be used only by the proxy, and are
instigated by the proxy: <span class="emphasis"><em>
LbxStartProxy</em></span>
, <span class="emphasis"><em>
LbxStopProxy</em></span>
, <span class="emphasis"><em>
LbxNewClient</em></span>
, <span class="emphasis"><em>
LbxSwitch</em></span>
, <span class="emphasis"><em>
LbxCloseClient</em></span>
, <span class="emphasis"><em>
LbxModifySequence</em></span>
, <span class="emphasis"><em>
LbxAllowMotion</em></span>
, <span class="emphasis"><em>
LbxInvalidateTag</em></span>
, <span class="emphasis"><em>
LbxTagData</em></span>
and <span class="emphasis"><em>
LbxQueryTag</em></span>
.
</p><p>
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.
</p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="requests_initiated_by_the_proxy_or_by_the_client"></a>Requests Initiated by the Proxy or by the Client</h4></div></div></div><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxQueryVersion</th></tr></thead><tbody><tr><td align="left">=>;</td></tr><tr><td class="protoargs" align="left">majorVersion: CARD16</td></tr><tr><td class="protoargs" align="left">minorVersion: CARD16</td></tr></tbody></table></div><p>
This request returns the major and minor version numbers of the LBX protocol.
</p><p>
The encoding of this request is on <a class="ulink" href="lbx.htm#34166" target="_top">See
LbxQueryVersion</a>.
</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="requests_initiated_or_substituted_by_the_proxy"></a>Requests Initiated or Substituted by the Proxy</h4></div></div></div><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxQueryExtension</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
nbytes</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
name</em></span>
: STRING8</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">num-requests: CARD8</td></tr><tr><td class="protoargs" align="left">present: BOOL</td></tr><tr><td class="protoargs" align="left">major-opcode: CARD8</td></tr><tr><td class="protoargs" align="left">first-event: CARD8</td></tr><tr><td class="protoargs" align="left">first-error: CARD8</td></tr><tr><td class="protoargs" align="left">reply-mask: LISTofMASK /* optional */</td></tr><tr><td class="protoargs" align="left">event-mask:LISTofMASK /* optional */</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
</td></tr></tbody></table></div><p>
This request is identical to the <span class="emphasis"><em>
QueryExtension</em></span>
request, with an additional field, and two optional additional fields. When
the client issues an <span class="emphasis"><em>
QueryExtension</em></span>
request, the proxy will substitute an <span class="emphasis"><em>
LbxQueryExtension</em></span>
request.
</p><p>
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.
</p><p>
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.
</p><p>
The encoding of this request is on <a class="ulink" href="lbx.htm#37117" target="_top">See
LbxQueryExtension</a>.
</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="control_requests_initiated_by_the_proxy"></a>Control Requests Initiated by the Proxy</h4></div></div></div><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxStartProxy</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
options</em></span>
: LISTofOPTION</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">choices: LISTofCHOICE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
LbxClient</em></span>
, <span class="emphasis"><em>
Alloc</em></span>
</td></tr><tr><td align="left">where:</td></tr><tr><td class="protoargs" align="left">OPTION [optcode: CARD8,</td></tr><tr><td class="protoargs" align="left"> len: OPTLEN,</td></tr><tr><td class="protoargs" align="left"> option: (See <a class="ulink" href="lbx.htm#35444" target="_top">See StartProxy Options</a>) ]</td></tr><tr><td class="protoargs" align="left">CHOICE [optcode: CARD8,</td></tr><tr><td class="protoargs" align="left"> len: OPTLEN,</td></tr><tr><td class="protoargs" align="left"> choice: (See <a class="ulink" href="lbx.htm#35444" target="_top">See StartProxy Options</a>) ]</td></tr></tbody></table></div><div class="table"><a id="idp53759488"></a><p class="title"><strong>Table 1. StartProxy Options</strong></p><div class="table-contents"><table summary="StartProxy Options" border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /><col align="left" class="c4" /></colgroup><thead><tr><th align="left">optcode</th><th align="left">option</th><th align="left">choice</th><th align="left">default</th></tr></thead><tbody><tr><td align="left">delta-proxy</td><td align="left">DELTAOPT</td><td align="left">DELTACHOICE</td><td align="left">entries=16, maxlen=64</td></tr><tr><td align="left">delta-server</td><td align="left">DELTAOPT</td><td align="left">DELTACHOICE</td><td align="left">entries=16, maxlen=64</td></tr><tr><td align="left">stream-comp</td><td align="left">LISTofNAMEDOPT</td><td align="left">INDEXEDCHOICE</td><td align="left">No Compression</td></tr><tr><td align="left">bitmap-comp</td><td align="left">LISTofSTRING8</td><td align="left">LISTofINDEXEDOPT</td><td align="left">No Compression</td></tr><tr><td align="left">pixmap-comp</td><td align="left">LISTofPIXMAPMETHOD</td><td align="left">LISTofPIXMAPCHOICE</td><td align="left">No Compression</td></tr><tr><td align="left">use-squish</td><td align="left">BOOL</td><td align="left">BOOL</td><td align="left">True</td></tr><tr><td align="left">use-tags</td><td align="left">BOOL</td><td align="left">BOOL</td><td align="left">True</td></tr><tr><td align="left">colormap</td><td align="left">LISTofSTRING8</td><td align="left">INDEXEDCHOICE</td><td align="left">No Colormap Grabbing</td></tr><tr><td align="left">extension</td><td align="left">NAMEDOPT</td><td align="left">INDEXEDCHOICE</td><td align="left">Extension Disabled</td></tr></tbody></table></div></div><br class="table-break" /><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">DELTAOPT [minN, maxN, prefN: CARD8</td></tr><tr><td class="protoargs" align="left"> minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen:
CARD8]</td></tr><tr><td class="protoargs" align="left">DELTACHOICE [entries, maxlen:
CARD8]</td></tr><tr><td class="protoargs" align="left">INDEXEDCHOICE [index: CARD8,</td></tr><tr><td class="protoargs" align="left"> data: LISTofBYTE]</td></tr><tr><td class="protoargs" align="left">INDEXEDOPT [index, opcode: CARD8]</td></tr><tr><td class="protoargs" align="left">NAMEDOPT [name: STRING8,</td></tr><tr><td class="protoargs" align="left"> detail: LISTofBYTE]</td></tr><tr><td class="protoargs" align="left">OPTLEN 1 or 3 CARD8</td></tr><tr><td class="protoargs" align="left"> where:</td></tr><tr><td class="protoargs" align="left"> (0 < in <= 0xFF): out =
in</td></tr><tr><td class="protoargs" align="left"> (0 <= in<= 0xFFFF): out[0] =
0; out[1] = in >> 8; out[2] = in& 0xFF;</td></tr><tr><td class="protoargs" align="left">PIXMAPMETHOD [name: STRING8,</td></tr><tr><td class="protoargs" align="left"> format-mask: BITMASK,</td></tr><tr><td class="protoargs" align="left"> depths: LISTofCARD8]</td></tr><tr><td class="protoargs" align="left">PIXMAPCHOICE [index, opcode: CARD8,</td></tr><tr><td class="protoargs" align="left"> format-mask: BITMASK,</td></tr><tr><td class="protoargs" align="left"> depths: LISTofCARD8]</td></tr><tr><td class="protoargs" align="left"> </td></tr></tbody></table></div><p>
This request negotiates LBX protocol options, and switches the proxy-server
connection from X11 protocol to LBX protocol.
</p><p>
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.
</p><p>
The server delta cache and proxy delta caches can be configured for number of
entries, and the length of entries. (See <a class="ulink" href="lbx.htm#22595" target="_top">See Delta
cache</a> for details.) The delta caches are configured using the <span class="emphasis"><em>
delta-server</em></span>
and <span class="emphasis"><em>
delta-proxy</em></span>
options. To configure a cache, the proxy sends the minimum, maximum and
preferred values for the number of cache entries, (<span class="emphasis"><em>
minN, maxN, prefN</em></span>
), and the length of the cache entries, (<span class="emphasis"><em>
minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen</em></span>
). The server’s reply fields, <span class="emphasis"><em>
entries</em></span>
and <span class="emphasis"><em>
maxlen</em></span>
, contains the values to use. These values must be within the ranges specified
by the proxy. The server may also specify an <span class="emphasis"><em>
entries</em></span>
value of 0 to disable delta caching. The cache entry lengths are specified in
units of 4 bytes.
</p><p>
The stream compression algorithm is selected using the <span class="emphasis"><em>
stream-comp </em></span>
option. (Stream compression is described in <a class="ulink" href="lbx.htm#11596" target="_top">See
Stream Compression</a>.) Each algorithm has a name that follows the naming
conventions in <a class="ulink" href="lbx.htm#13570" target="_top">See Algorithm Naming</a>. To
negotiate using the stream-comp option, the proxy lists its available
compressors. For each candidate algorithm, the proxy sends the name in the
<span class="emphasis"><em>
name</em></span>
field, and uses the <span class="emphasis"><em>
detail</em></span>
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.
</p><p>
Bitmap compression is negotiated using the <span class="emphasis"><em>
bitmap-comp</em></span>
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 <span class="emphasis"><em>
opcode</em></span>
field gives the value for use in requests. The algorithm names follow the
conventions in <a class="ulink" href="lbx.htm#13570" target="_top">See Algorithm Naming</a>.
</p><p>
Pixmap compression is negotiated using the <span class="emphasis"><em>
pixmap-comp</em></span>
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 <a class="ulink" href="lbx.htm#13570" target="_top">See Algorithm
Naming</a>.
</p><p>
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 <span class="emphasis"><em>
use-squish</em></span>
is set to true in the request.
</p><p>
Tag caching, described in <a class="ulink" href="lbx.htm#11018" target="_top">See Tags</a>, 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 <span class="emphasis"><em>
use-tag</em></span>
is set to true in the request.
</p><p>
The colormap option is used to negotiate what color matching algorithm will be
used by the proxy when the proxy uses the <span class="emphasis"><em>
LbxAllocColor</em></span>
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 <span class="emphasis"><em>
LbxAllocColor</em></span>
, <span class="emphasis"><em>
LbxGrabCmap</em></span>
, and <span class="emphasis"><em>
LbxReleaseCmap</em></span>
requests will not be used.
</p><p>
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 <a class="ulink" href="lbx.htm#13570" target="_top">See Algorithm Naming</a>. 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 <span class="emphasis"><em>
LbxStartProxy</em></span>
message. This index is followed by extension-specific information. The server
does not respond to extensions it does not recognize.
</p><p>
An <span class="emphasis"><em>
LbxClient</em></span>
error is returned when a client which is already communicating through an LBX
proxy to the X server sends a <span class="emphasis"><em>
LbxStartProxy</em></span>
request.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#27452" target="_top">See
LbxStartProxy</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxStopProxy</th></tr></thead><tbody><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
LbxClient</em></span>
</td></tr></tbody></table></div><p>
This request terminates the connection between the proxy and X server, and
terminates any clients connected through the proxy.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#23471" target="_top">See
LbxStopProxy</a>.
</p><p>
An <span class="emphasis"><em>
LbxClient</em></span>
error is returned if the requesting client is not an LBX proxy.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxNewClient</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
byte-order</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client-id</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
protocol-major-version</em></span>
: CARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
protocol-minor-version:</em></span>
CARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
authorization-protocol-name</em></span>
: STRING8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
authorization-protocol-data</em></span>
: STRING8</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">Core X reply (if connection is rejected)</td></tr><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">OR</td></tr><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">success: BOOL</td></tr><tr><td class="protoargs" align="left">change-type: {NoDeltas, NormalClientDeltas,
AppGroupDeltas}</td></tr><tr><td class="protoargs" align="left">protocol-major-version: CARD16</td></tr><tr><td class="protoargs" align="left">protocol-minor-version: CARD16</td></tr><tr><td class="protoargs" align="left">tag-id: CARD32</td></tr><tr><td class="protoargs" align="left">length: CARD16</td></tr><tr><td class="protoargs" align="left">connection-data: CONINFO or CONDIF or
CONDIFROOT</td></tr><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">where:</td></tr><tr><td class="protoargs" align="left">CONINFO: (the "additional data"
portion of the core connection reply for successes)</td></tr><tr><td class="protoargs" align="left">CONDIF: [resource-id-base: CARD32,</td></tr><tr><td class="protoargs" align="left"> root-input-masks: LISTofSETofEVENT]</td></tr><tr><td class="protoargs" align="left">CONDIFROOT: [resource-id-base:
CARD32,</td></tr><tr><td class="protoargs" align="left"> root: WINDOW</td></tr><tr><td class="protoargs" align="left"> root-visual: VISUALID</td></tr><tr><td class="protoargs" align="left"> default-colormap: COLORMAP</td></tr><tr><td class="protoargs" align="left"> white-pixel, black-pixel: CARD32</td></tr><tr><td class="protoargs" align="left"> root-input-masks: LISTofSETofEVENT]</td></tr></tbody></table></div><p>
Errors: LbxClient, Alloc
</p><p>
This request, which is sent by the proxy over the control connection, creates a
new virtual connection to the server.
</p><p>
Much of the information in the <span class="emphasis"><em>
LbxNewClient</em></span>
request and reply is identical to the connection setup and reply information
in the core X protocol.
</p><p>
For the <span class="emphasis"><em>
LbxNewClient</em></span>
request, the field unique to LBX is client-id. For the <span class="emphasis"><em>
LbxNewClient</em></span>
reply, <span class="emphasis"><em>
tag-id</em></span>
and <span class="emphasis"><em>
change-type</em></span>
are fields unique to LBX, and the contents of connection-data may be different
in LBX from the core X protocol (see below).
</p><p>
The proxy assigns each virtual connection a unique identifier using the
<span class="emphasis"><em>
client-id</em></span>
field in the <span class="emphasis"><em>
LbxNewClient</em></span>
request. This client-id is used in the LBX protocol to specify the current
client (see the <span class="emphasis"><em>
LbxSwitch</em></span>
request and the <span class="emphasis"><em>
LbxSwitchEvent</em></span>
). client-id 0 is reserved for the proxy control connection. An <span class="emphasis"><em>
LbxClient</em></span>
error will result if the <span class="emphasis"><em>
LbxNewClient</em></span>
request contains a client-id of 0 or an already in use client-id.
</p><p>
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 <span class="emphasis"><em>
Authenticate</em></span>
reply.
</p><p>
If the <span class="emphasis"><em>
change-type</em></span>
field is set to <span class="emphasis"><em>
NoDeltas</em></span>
, then <span class="emphasis"><em>
connection-data</em></span>
is sent using the CONINFO structure, which is identical to the additional data
of the core connection reply. If the <span class="emphasis"><em>
tag-id</em></span>
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 <span class="emphasis"><em>
LbxInvalidateTag</em></span>
event is received for that tag.
</p><p>
When the <span class="emphasis"><em>
change-type</em></span>
field is not set to <span class="emphasis"><em>
NoDeltas</em></span>
, then connection data is sent as changes against connection information
previously sent to the proxy. The <span class="emphasis"><em>
tag-id</em></span>
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.
</p><p>
If the <span class="emphasis"><em>
change-type</em></span>
field is set to <span class="emphasis"><em>
NormalClientDeltas</em></span>
, then <span class="emphasis"><em>
connection-data</em></span>
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.
</p><p>
If the <span class="emphasis"><em>
change-type</em></span>
field is set to <span class="emphasis"><em>
AppGroupDeltas</em></span>
, then <span class="emphasis"><em>
connection-data</em></span>
is sent using the CONDIFROOT structure. The <span class="emphasis"><em>
root</em></span>
, <span class="emphasis"><em>
root-visual</em></span>
, and <span class="emphasis"><em>
default-colormap</em></span>
fields, when nonzero, are substituted for the corresponding fields in the
reference connection information. The <span class="emphasis"><em>
white-pixel</em></span>
and <span class="emphasis"><em>
black-pixel</em></span>
fields are substituted only when the <span class="emphasis"><em>
default-colormap</em></span>
field of the reply is non-zero. When <span class="emphasis"><em>
default-colormap</em></span>
field of the reply is zero, so are <span class="emphasis"><em>
white-pixel</em></span>
and <span class="emphasis"><em>
black-pixel</em></span>
. The first entry in the <span class="emphasis"><em>
root-input-masks</em></span>
field is the current-input-mask for the default root window. The remaining
entries in <span class="emphasis"><em>
root-input-masks</em></span>
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
<span class="emphasis"><em>
root-input-masks</em></span>
. These screens are at the end of screen list in the reference connection
information.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#15166" target="_top">See The
description of this request is on page 13.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxCloseClient</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
LbxClient</em></span>
</td></tr></tbody></table></div><p>
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 <span class="emphasis"><em>
LbxNewClient</em></span>
request, the server will send the <span class="emphasis"><em>
LbxClient</em></span>
error.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#21121" target="_top">See The
description of this request is on page 12.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxSwitch</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
LbxClient</em></span>
</td></tr></tbody></table></div><p>
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.
</p><p>
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 <span class="emphasis"><em>
LbxNewClient</em></span>
request, an <span class="emphasis"><em>
LbxClient</em></span>
error is returned.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#36790" target="_top">See
LbxSwitch</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxSync</th></tr></thead><tbody><tr><td align="left">=></td></tr></tbody></table></div><p>
The sync request causes the server to send a reply when all requests before the
sync request have been processed.
</p><p>
The encoding for this client is on <a class="ulink" href="lbx.htm#21186" target="_top">See
LbxSync</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxModifySequence</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
adjust</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: None</td></tr></tbody></table></div><p>
This request advances the sequence number of the virtual client connection by
the specified amount. The proxy sends the <span class="emphasis"><em>
LbxModifySequence</em></span>
request to the server when it replies to a client request without forwarding
the client request on to the X server.
</p><p>
The encoding for this client is on <a class="ulink" href="lbx.htm#10940" target="_top">See The
description of this request is on page 13.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxAllowMotion</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
num</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: None</td></tr></tbody></table></div><p>
This request controls the delivery of optional motion notify events, as
described in <a class="ulink" href="lbx.htm#15503" target="_top">See Motion events</a>. The num
field specifies an increase in the allowed number of motion notify events sent.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#11897" target="_top">See The
description of this request is on page 14.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxInvalidateTag</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr></tbody></table></div><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#37545" target="_top">See
LbxInvalidateTag</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxTagData</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
real-length</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
data</em></span>
: LISTofBYTE</td></tr></tbody></table></div><p>
This request specifies the data associated with a previously assigned tag. It
is sent in two circumstances: in response to receiving a <span class="emphasis"><em>
SendTagDataEvent</em></span>
, 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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#37174" target="_top">See
LbxTagData</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGrabCmap</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cmap</em></span>
: Colormap </td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
smart-grab</em></span>
: BOOL</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
large-pixel: </em></span>
BOOL /* optional */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
auto-release: </em></span>
BOOL /* optional */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
three-channels</em></span>
: BOOL /* optional */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
bits-per-rgb: </em></span>
CARD4 /* optional */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cells</em></span>
: LISTofCHAN /* optional */</td></tr><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">where:</td></tr><tr><td class="protoargs" align="left">CHAN: LISTofLBXPIXEL</td></tr><tr><td class="protoargs" align="left">LBXPIXEL: PIXELPRIVATE or PIXELPRIVATERANGE
or </td></tr><tr><td class="protoargs" align="left"> PIXELALLOC or PIXELALLOCRANGE </td></tr><tr><td class="protoargs" align="left">PIXEL: CARD8 or CARD16</td></tr><tr><td class="protoargs" align="left">PIXELPRIVATE: [ pixel: PIXEL ]</td></tr><tr><td class="protoargs" align="left">PIXELPRIVATERANGE: [ first-pixel,
last-pixel: PIXEL]</td></tr><tr><td class="protoargs" align="left">PIXELALLOC: [ pixel: PIXEL,</td></tr><tr><td class="protoargs" align="left"> color: COLORSINGLE or COLORTRIPLE]</td></tr><tr><td class="protoargs" align="left">PIXELALLOCRANGE: [ first-pixel,
last-pixel: PIXEL,</td></tr><tr><td class="protoargs" align="left"> colors: LISTofCOLORSINGLE or
LISTofCOLORTRIPLE]</td></tr><tr><td class="protoargs" align="left">COLORSINGLE: [ value: CARD8 or CARD16
]</td></tr><tr><td class="protoargs" align="left">COLORTRIPLE: [ r, g, b:
COLORSINGLE]</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Colormap</em></span>
</td></tr></tbody></table></div><p>
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 <span class="emphasis"><em>
smart-grab</em></span>
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.
</p><p>
Once the proxy has received the reply, it can use the <span class="emphasis"><em>
LbxAllocColor</em></span>
request to allocate new colormap cells without the performance penalty of
round trips. The proxy is still permitted to use the normal colormap and
<span class="emphasis"><em>
LbxIncrementPixel</em></span>
requests while the colormap is grabbed. The grab is valid across all virtual
connections of the proxy.
</p><p>
The <span class="emphasis"><em>
LbxGrabCmap</em></span>
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.
</p><p>
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<span class="emphasis"><em>
ReleaseCmap</em></span>
event to the proxy holding the grab, which then issues an <span class="emphasis"><em>
LbxReleaseCmap</em></span>
request.
</p><p>
The server and other proxies may free colormap cells in a colormap grabbed by a
proxy. The server will send an <span class="emphasis"><em>
LbxFreeCells</em></span>
event to the proxy that currently has the colormap grabbed when the cell
reference count reaches 0.
</p><p>
If the colormap is a of a static visual type, such as <span class="emphasis"><em>
StaticGray</em></span>
, <span class="emphasis"><em>
StaticColor</em></span>
, <span class="emphasis"><em>
GrayScale</em></span>
, or <span class="emphasis"><em>
TrueColor</em></span>
, then the proxy’s grab is immediately released by the server, and the proxy
must use <span class="emphasis"><em>
LbxIncrementPixel</em></span>
requests in place of <span class="emphasis"><em>
LbxAllocColor</em></span>
requests for this colormap.
</p><p>
If the cmap field does not refer to a valid colormap or the colormap is already
grabbed by this proxy then a <span class="emphasis"><em>
Colormap</em></span>
error is generated.
</p><p>
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.
</p><p>
The <span class="emphasis"><em>
large-pixel</em></span>
argument, if True, specifies that PIXEL indices will be listed as CARD16
quantities instead of CARD8. The<span class="emphasis"><em>
auto-release</em></span>
field, if True, indicates that this colormap is of a static visual type and
the proxy’s grab is immediately released by the server.
</p><p>
If <span class="emphasis"><em>
three-channels</em></span>
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 <span class="emphasis"><em>
DirectColor</em></span>
or <span class="emphasis"><em>
TrueColor</em></span>
.
</p><p>
If <span class="emphasis"><em>
three-channels</em></span>
is True, separate red, green and blue channel lists are enclosed, for
describing a <span class="emphasis"><em>
DirectColor</em></span>
or <span class="emphasis"><em>
TrueColor</em></span>
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.
</p><p>
The <span class="emphasis"><em>
bits-per-rgb</em></span>
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.
</p><p>
The list describing current colormap allocations contains entries of the
following types:
</p><p>
An LBXPIXELPRIVATE entry indicates that the pixel in the <span class="emphasis"><em>
pixel </em></span>
field is unavailable for allocation.
</p><p>
An LBXPIXELPRIVATERANGE entry indicates that a contiguous range of pixels are
unavailable for allocation. The range is <span class="emphasis"><em>
first-pixel</em></span>
to <span class="emphasis"><em>
last-pixel</em></span>
, and includes <span class="emphasis"><em>
last-pixel</em></span>
.
</p><p>
An LBXPIXELALLOC entry indicates that the pixel in the <span class="emphasis"><em>
pixel </em></span>
field is allocated as a read-only pixel. The <span class="emphasis"><em>
color</em></span>
field carries the color information of the pixel.
</p><p>
An LBXPIXELALLOCRANGE entry indicates that a contiguous range of pixels are
allocated as read-only. The range starts <span class="emphasis"><em>
first-pixel</em></span>
to <span class="emphasis"><em>
last-pixel</em></span>
, and includes <span class="emphasis"><em>
last-pixel</em></span>
. These fields are followed by a list of COLORSINGLE or COLORTRIPLE, depending
on the value of <span class="emphasis"><em>
three-channels</em></span>
.
</p><p>
A NEXTCHANNEL entry indicates that the next channel of the colormap will be
described.
</p><p>
A LISTEND entry indicates the end of the colormap description.
</p><p>
All pixels not described in the reply are unallocated.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#17198" target="_top">See
LbxGrabCmap</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxReleaseCmap</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cmap</em></span>
: Colormap</td></tr></tbody></table></div><p>
This request releases the specified grabbed colormap. If the <span class="emphasis"><em>
cmap</em></span>
field does not refer to a colormap, a <span class="emphasis"><em>
BadColormap</em></span>
error is produced.
</p><p>
The proxy must remember the state of the colormap when the <span class="emphasis"><em>
LbxReleaseCmap</em></span>
request is issued if this proxy may at some future time issue another
<span class="emphasis"><em>
LbxGrabCmap</em></span>
request on this colormap before the state of the colormap changes.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#14796" target="_top">See
LbxReleaseCmap</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxInternAtoms</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
count</em></span>
: CARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
names: LISTofSTRING8</em></span>
</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
atoms</em></span>
: LISTofATOM</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
</td></tr></tbody></table></div><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#34140" target="_top">See
LbxInternAtoms</a>.
</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="substitution_requests"></a>Substitution Requests</h4></div></div></div><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxAllocColor</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cmap</em></span>
: Colormap</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
pixel</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
red</em></span>
, <span class="emphasis"><em>
green</em></span>
, <span class="emphasis"><em>
blue</em></span>
: CARD16</td></tr></tbody></table></div><p>
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 <span class="emphasis"><em>
AllocColor</em></span>
and <span class="emphasis"><em>
AllocNamedColor</em></span>
requests.
</p><p>
The <span class="emphasis"><em>
pixel</em></span>
field identifies the colormap cell to allocate. The <span class="emphasis"><em>
red</em></span>
, <span class="emphasis"><em>
green</em></span>
, and <span class="emphasis"><em>
blue</em></span>
fields are the hardware specific color values of the corresponding fields of
the core <span class="emphasis"><em>
AllocColor</em></span>
request. The mapping to hardware specific colormap values by the proxy is
performed using the color algorithm negotiated by <span class="emphasis"><em>
LbxStartProxy</em></span>
.
</p><p>
For colormaps of static visual types, the <span class="emphasis"><em>
LbxIncrementPixel</em></span>
request is used instead of LBX <span class="emphasis"><em>
AllocColor</em></span>
.
</p><p>
If the <span class="emphasis"><em>
cmap</em></span>
field does not identify a grabbed colormap then a <span class="emphasis"><em>
BadAccess</em></span>
error is produced. If the <span class="emphasis"><em>
pixel</em></span>
field refers to a read-write entry, or the pixel field refers to a pixel
outside of the range of this colormap, a <span class="emphasis"><em>
BadAlloc</em></span>
error is produced.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#28429" target="_top">See
LbxAllocColor</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxIncrementPixel</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cmap</em></span>
: COLORMAP</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
pixel</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: None</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
AllocColor</em></span>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#38053" target="_top">See The
description of this request is on page 14.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxDelta</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
count</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cache-index</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
diffs</em></span>
: LISTofDIFFITEM</td></tr></tbody></table></div><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#39838" target="_top">See The
description of this request is on page 18.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGetModifierMapping</th></tr></thead><tbody><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
keyspermod</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
keycodes</em></span>
: LISTofKEYCODE /* optional */</td></tr></tbody></table></div><p>
This request is identical to the core <span class="emphasis"><em>
GetModifierMapping</em></span>
request, with the addition of a tag being returned in the reply. See <a class="ulink" href="lbx.htm#26534" target="_top">See Tag Substitution in Requests</a> for a description
of the <span class="emphasis"><em>
tag</em></span>
field and optional fields.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#40057" target="_top">See
LbxGetModifierMapping</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGetKeyboardMapping</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
firstKeyCode</em></span>
: KEYCODE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
count</em></span>
: CARD8</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
keysperkeycode</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
keysyms</em></span>
: LISTofKEYSYM /* optional */</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Value</em></span>
</td></tr></tbody></table></div><p>
This request is identical to the X <span class="emphasis"><em>
GetKeyboardMapping</em></span>
protocol request, with the addition that a tag is returned in the reply. See
<a class="ulink" href="lbx.htm#26534" target="_top">See Tag Substitution in Requests</a> for a
description of the <span class="emphasis"><em>
tag</em></span>
field and optional fields.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#21702" target="_top">See
LbxGetKeyboardMapping</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGetWinAttrAndGeom</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
window</em></span>
: WINDOW</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">visual: VISUALID</td></tr><tr><td class="protoargs" align="left">class: {InputOutput, InputOnly}</td></tr><tr><td class="protoargs" align="left">bit-gravity: BITGRAVITY</td></tr><tr><td class="protoargs" align="left">win-gravity: WINGRAVITY</td></tr><tr><td class="protoargs" align="left">backing-store: {NotUseful, WhenMapped,
Always}</td></tr><tr><td class="protoargs" align="left">backing-planes: CARD32</td></tr><tr><td class="protoargs" align="left">backing-pixel: CARD32</td></tr><tr><td class="protoargs" align="left">save-under: BOOL</td></tr><tr><td class="protoargs" align="left">colormap: COLORMAP or None</td></tr><tr><td class="protoargs" align="left">map-is-installed: BOOL</td></tr><tr><td class="protoargs" align="left">map-state: {Unmapped, Unviewable,
Viewable}</td></tr><tr><td class="protoargs" align="left">all-event-masks, your-event-mask:
SETofEVENT</td></tr><tr><td class="protoargs" align="left">do-not-propagate-mask: SETofDEVICEEVENT</td></tr><tr><td class="protoargs" align="left">override-redirect: BOOL</td></tr><tr><td class="protoargs" align="left">root: WINDOW</td></tr><tr><td class="protoargs" align="left">depth: CARD8</td></tr><tr><td class="protoargs" align="left">x, y: INT16</td></tr><tr><td class="protoargs" align="left">width, height, border-width: CARD16</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Window</em></span>
</td></tr></tbody></table></div><p>
<span class="emphasis"><em>
GetWindowAttributes</em></span>
and <span class="emphasis"><em>
GetGeometry</em></span>
are frequently used together in the X protocol. <span class="emphasis"><em>
LbxGetWinAttrAndGeom</em></span>
allows the proxy to request the same information in one round trip.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#41440" target="_top">See
LbxGetWinAttrAndGeom</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxQueryFont</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
font</em></span>
: FONTABLE</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">compression: BOOL</td></tr><tr><td class="protoargs" align="left">tag: CARD32</td></tr><tr><td class="protoargs" align="left">font-info: FONTINFO /* optional
*/</td></tr><tr><td class="protoargs" align="left">char-infos: LISTofCHARINFO or LISTofLBXCHARINFO
/* optional */</td></tr><tr><td class="protoargs" align="left">where:</td></tr><tr><td class="protoargs" align="left">LBXCHARINFO: [left-side-bearing:
INT6</td></tr><tr><td class="protoargs" align="left"> right-side-bearing: INT7</td></tr><tr><td class="protoargs" align="left"> character-width: INT6</td></tr><tr><td class="protoargs" align="left"> ascent: INT6</td></tr><tr><td class="protoargs" align="left"> descent: INT7]</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Font,Alloc</em></span>
</td></tr></tbody></table></div><p>
This request is used to replace the core <span class="emphasis"><em>
QueryFont</em></span>
request and has identical semantics.
</p><p>
See <a class="ulink" href="lbx.htm#26534" target="_top">See Tag Substitution in Requests</a> for a
description of the <span class="emphasis"><em>
tag</em></span>
field and optional fields.
</p><p>
The <span class="emphasis"><em>
compression</em></span>
field is True if the <span class="emphasis"><em>
char-infos</em></span>
field is represented using LBXCHARINFO.
</p><p>
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 <span class="emphasis"><em>
font_info</em></span>
field of the font.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#24597" target="_top">See
LbxQueryFont</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxChangeProperty</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
window</em></span>
: WINDOW</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
property</em></span>
: ATOM</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
type</em></span>
: ATOM</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
format</em></span>
: {0,8,16,32}</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
mode</em></span>
: {Replace, Prepend, Append}</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
nUnits</em></span>
: CARD32</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">tag: CARD32</td></tr></tbody></table></div><p>
This request is sent to the server when the client sends an X <span class="emphasis"><em>
ChangeProperty </em></span>
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 <span class="emphasis"><em>
LbxStopProxy</em></span>
request, or exiting, the proxy must send Lbx<span class="emphasis"><em>
TagData</em></span>
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.
</p><p>
If the <span class="emphasis"><em>
mode</em></span>
field is <span class="emphasis"><em>
Prepend</em></span>
or <span class="emphasis"><em>
Append</em></span>
, the tag refers only to the prepended or appended data.
</p><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#18013" target="_top">See
LbxChangeProperty</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGetProperty</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
window</em></span>
: WINDOW</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
property</em></span>
: ATOM</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
type</em></span>
: ATOM or AnyPropertyType</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
long-offset</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
long-length</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
delete</em></span>
: CARD8</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">type: ATOM or None</td></tr><tr><td class="protoargs" align="left">format: {0, 8, 16, 32}</td></tr><tr><td class="protoargs" align="left">bytes-after: CARD32</td></tr><tr><td class="protoargs" align="left">nItems: CARD32</td></tr><tr><td class="protoargs" align="left">tag: CARD32</td></tr><tr><td class="protoargs" align="left">value: LISTofINT8 or LISTofINT16 or
LISTofINT32</td></tr></tbody></table></div><p>
This request may be used by the proxy as a substitution for a core <span class="emphasis"><em>
GetProperty</em></span>
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.
</p><p>
The <span class="emphasis"><em>
LbxGetProperty</em></span>
request has the same arguments as the core <span class="emphasis"><em>
GetProperty</em></span>
request. The reply for <span class="emphasis"><em>
LbxGetProperty</em></span>
has all of the fields from the core <span class="emphasis"><em>
GetProperty</em></span>
reply, but has the additional fields of <span class="emphasis"><em>
nItems</em></span>
and <span class="emphasis"><em>
tag</em></span>
.
</p><p>
In order to utilize tags in <span class="emphasis"><em>
LbxGetProperty</em></span>
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 <span class="emphasis"><em>
LbxGetProperty</em></span>
reply with a new <span class="emphasis"><em>
tag</em></span>
, <span class="emphasis"><em>
nItems</em></span>
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.
</p><p>
In response to future <span class="emphasis"><em>
LbxGetProperty</em></span>
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 <span class="emphasis"><em>
LbxGetProperty</em></span>
reply without the actual property data. In this case, the reply would include
a non-zero <span class="emphasis"><em>
tag</em></span>
, a zero reply length, and no data for value.
</p><p>
If the server chooses not to generate a tagged reply to <span class="emphasis"><em>
LbxGetProperty</em></span>
, or for some reason is unable to do so, it would send a reply with a <span class="emphasis"><em>
tag</em></span>
of zero, the size of the property data in the reply length field, and the
complete property data in value.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#13863" target="_top">See
LbxGetProperty</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyPoint</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
points</em></span>
: LISTofLBXPOINT</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyPoint</em></span>
request. Not all <span class="emphasis"><em>
PolyPoint</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyPoint</em></span>
requests.
</p><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#29719" target="_top">See
LbxPolyPoint</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyLine</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
points</em></span>
: LISTofLBXPOINT</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyLine</em></span>
request. Not all <span class="emphasis"><em>
PolyLine</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyline</em></span>
requests.
</p><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#31086" target="_top">See The
description of this request is on page 21.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolySegment</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
segments</em></span>
: LISTofLBXSEGMENT</td></tr><tr><td class="protoargs" align="left"> </td></tr><tr><td class="protoargs" align="left">where:</td></tr><tr><td class="protoargs" align="left">LBXSEGEMENT; [x1, y1, x2, y2: LBXINT16]</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolySegment</em></span>
request. Not all <span class="emphasis"><em>
PolySegment</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolySegment</em></span>
requests.
</p><p>
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].
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#27528" target="_top">See
LbxPolySegment</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyRectangle</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
rectangles</em></span>
: LISTofLBXRECTANGLE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyRectangle</em></span>
request. Not all <span class="emphasis"><em>
PolyRectangle</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyRectangle</em></span>
requests.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#33628" target="_top">See The
description of this request is on page 22.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyArc</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
arcs</em></span>
: LISTofLBXARC</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyArc</em></span>
request. Not all <span class="emphasis"><em>
PolyArc</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyArc</em></span>
requests.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#25855" target="_top">See
LbxPolyArc</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyFillRectangle</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
rectangles</em></span>
: LISTofLBXRECTANGLE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyFillRectangle</em></span>
request. Not all <span class="emphasis"><em>
PolyFillRectangle</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyFillRectangle</em></span>
requests.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#26399" target="_top">See
LbxPolyFillRectangle</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyFillArc</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
arcs</em></span>
: LISTofLBXARC</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyFillArc</em></span>
request. Not all <span class="emphasis"><em>
PolyFillArc</em></span>
requests can be represented as <span class="emphasis"><em>
LbxPolyFillArc</em></span>
requests.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#19081" target="_top">See The
description of this request is on page 22.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxFillPoly</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
shape</em></span>
: BYTE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
points</em></span>
: LISTofLBXPOINT</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
FillPoly</em></span>
request. Not all <span class="emphasis"><em>
FillPoly</em></span>
requests can be represented as <span class="emphasis"><em>
LbxFillPoly</em></span>
requests.
</p><p>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#24998" target="_top">See
LbxFillPoly</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxCopyArea</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
srcCache</em></span>
: CARD8 /* source drawable */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-Drawable</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-x</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
width</em></span>
: LBXCARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
height</em></span>
: LBXCARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
dst-x</em></span>
: LBXPINT16 </td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
dst-y</em></span>
: LBXPINT16</td></tr><tr><td class="protoerror" align="left">Errors: Those given for the corresponding X
request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
CopyArea</em></span>
request for requests within its encoding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#10231" target="_top">See
LbxCopyArea</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxCopyPlane</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
bit-plane</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-cache</em></span>
: CARD8 /* cache reference for source drawable */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-drawable</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-x</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
src-y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
width</em></span>
: LBXCARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
height</em></span>
: LBXCARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
dst-x</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
dst-y</em></span>
: LBXPINT16</td></tr><tr><td class="protoerror" align="left">Errors: Those given for the corresponding X
request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
CopyPlane</em></span>
request for requests within its coding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#18847" target="_top">See
LbxCopyPlane</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyText8</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
x</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
items</em></span>
: LISTofTEXTITEM8</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
, and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyText8</em></span>
request for requests within its encoding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#39640" target="_top">See The
description of this request is on page 23.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPolyText16</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
x:</em></span>
LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
items</em></span>
: LISTofTEXTITEM16</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
, and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
PolyText16</em></span>
request for requests within its encoding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#32634" target="_top">See The
description of this request is on page 24.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxImageText8</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
nChars</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
x</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
string</em></span>
: STRING8</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
, and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
ImageText8</em></span>
request for requests within its encoding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#17018" target="_top">See The
description of this request is on page 24.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxImageText16</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
nChars</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left">x: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
string</em></span>
: STRING16</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
, and those given for the corresponding X request.</td></tr></tbody></table></div><p>
This request replaces the <span class="emphasis"><em>
ImageText16</em></span>
request for requests within its encoding range.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#23910" target="_top">See The
description of this request is on page 24.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxPutImage</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
compression-method</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
format</em></span>
: {<span class="emphasis"><em>
Bitmap</em></span>
, <span class="emphasis"><em>
XYPixmap</em></span>
, <span class="emphasis"><em>
ZPixmap</em></span>
} /* packed */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
gc-and-drawable: </em></span>
LBXGCANDDRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
width</em></span>
, <span class="emphasis"><em>
height</em></span>
: LBXCARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
dst-x</em></span>
, <span class="emphasis"><em>
dst-y</em></span>
: LBXPINT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
depth</em></span>
: CARD8 /* packed */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
left-pad</em></span>
: CARD8 /* packed */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
pad-bytes</em></span>
: CARD8 /* packed */</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
data</em></span>
:LISTofBYTE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
, <span class="emphasis"><em>
Value</em></span>
</td></tr></tbody></table></div><p>
When the request can be usefully compressed, this request replaces the
<span class="emphasis"><em>
PutImage</em></span>
request. The <span class="emphasis"><em>
compression-method</em></span>
parameter contains the opcode of a compression method returned in the
<span class="emphasis"><em>
LbxStartProxy</em></span>
reply. The <span class="emphasis"><em>
pad-bytes</em></span>
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 <span class="emphasis"><em>
Value</em></span>
error.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#12268" target="_top">See
LbxPutImage</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxGetImage</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
drawable</em></span>
: DRAWABLE</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
x</em></span>
, <span class="emphasis"><em>
y</em></span>
: INT16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
width</em></span>
, <span class="emphasis"><em>
height</em></span>
: CARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
plane-mask</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
format</em></span>
: {XYPixmap, ZPixmap}</td></tr><tr><td align="left">=></td></tr><tr><td class="protoargs" align="left">depth: CARD8</td></tr><tr><td class="protoargs" align="left">x-length: CARD32</td></tr><tr><td class="protoargs" align="left">visual: VISUALID or None</td></tr><tr><td class="protoargs" align="left">compression-method: CARD8</td></tr><tr><td class="protoargs" align="left">data: LISTofBYTE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc,Match,Value</em></span>
</td></tr></tbody></table></div><p>
This request can replace the <span class="emphasis"><em>
GetImage</em></span>
request. The same semantics apply, with the following exceptions.
</p><p>
The <span class="emphasis"><em>
compression-method</em></span>
field contains the opcode of the compression method used in the reply. The
compression opcodes are supplied in the <span class="emphasis"><em>
LbxStartProxy</em></span>
reply. The <span class="emphasis"><em>
x-length </em></span>
field<span class="emphasis"><em>
</em></span>
contains the length of the uncompressed version of the reply in 4 byte units.
</p><p>
A <span class="emphasis"><em>
Value</em></span>
error is returned if the format is not recognized by the X server. A <span class="emphasis"><em>
Match</em></span>
error is returned under the same circumstances as described by the <span class="emphasis"><em>
GetImage</em></span>
request.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#10066" target="_top">See
LbxGetImage</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxBeginLargeRequest</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
large-request-length</em></span>
: CARD32</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
</td></tr></tbody></table></div><p>
This request, along with the Lbx<span class="emphasis"><em>
LargeRequestData</em></span>
and Lbx<span class="emphasis"><em>
EndLargeRequest</em></span>
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.
</p><p>
After a <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
request is sent, multiple <span class="emphasis"><em>
LbxLargeRequestData</em></span>
requests are sent to transport all of the data in the large request, and
finally an <span class="emphasis"><em>
LbxEndLargeRequest</em></span>
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.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#22013" target="_top">See The
description of this request is on page 25.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxLargeRequestData</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
data</em></span>
: LISTofBYTE</td></tr><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Alloc</em></span>
</td></tr></tbody></table></div><p>
This request is used to carry the segments of a larger request, as described in
the definition of <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
. The data must be carried in order, starting with the request header, and each
segment must be multiples of 4 bytes long. If the <span class="emphasis"><em>
LbxLargeRequestData</em></span>
is not preceded by a corresponding <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
, a <span class="emphasis"><em>
BadAlloc</em></span>
error is generated.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#31469" target="_top">See The
description of this request is on page 26.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxEndLargeRequest</th></tr></thead><tbody><tr><td class="protoerror" align="left">Errors: <span class="emphasis"><em>
Length, Alloc</em></span>
</td></tr></tbody></table></div><p>
As described in the definition of <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
, <span class="emphasis"><em>
LbxEndLargeRequest</em></span>
is used to signal the end of a series of <span class="emphasis"><em>
LargeRequestData</em></span>
requests. If the total length of the data transported by the <span class="emphasis"><em>
LbxLargeRequestData</em></span>
requests does not match the large-request-length field of the preceding
<span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
request, then a <span class="emphasis"><em>
Length</em></span>
error occurs. If the <span class="emphasis"><em>
LbxEndLargeRequest</em></span>
is not preceded by a corresponding <span class="emphasis"><em>
LbxBeginLargeRequest</em></span>
, a <span class="emphasis"><em>
BadAlloc</em></span>
error is generated. The request is executed in order for that client as if it
were the request after the request preceding <span class="emphasis"><em>
LbxEndLargeRequest</em></span>
.
</p><p>
The encoding for this request is on <a class="ulink" href="lbx.htm#31037" target="_top">See
LbxEndLargeRequest</a>.
</p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="events"></a>Events</h3></div></div></div><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxSwitchEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client</em></span>
: CARD32</td></tr></tbody></table></div><p>
Notify the proxy that the subsequent replies, events, and errors are relative
to the specified client.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#17348" target="_top">See
LbxSwitchEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxCloseEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client</em></span>
: CARD32</td></tr></tbody></table></div><p>
Notify the proxy that the specified client's connection to the server is closed.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#41814" target="_top">See The
description of this event is on page 27.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxInvalidateTagEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag-type</em></span>
: {Modmap, Keymap, Property, Font, ConnInfo}</td></tr></tbody></table></div><p>
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: <span class="emphasis"><em>
LbxTagTypeModmap</em></span>
, <span class="emphasis"><em>
LbxTagTypeKeymap</em></span>
, <span class="emphasis"><em>
LbxTagTypeProperty</em></span>
, <span class="emphasis"><em>
LbxTagTypeFont</em></span>
, <span class="emphasis"><em>
LbxTagTypeConnInfo</em></span>
.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#34406" target="_top">See
LbxInvalidateTagEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxSendTagDataEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag</em></span>
: CARD32</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
tag-type</em></span>
: {Property}</td></tr></tbody></table></div><p>
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 <span class="emphasis"><em>
SendTagData</em></span>
by sending a <span class="emphasis"><em>
TagData</em></span>
request to the server. The tag type may be one of the following values:
<span class="emphasis"><em>
LbxTagTypeProperty</em></span>
.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#22353" target="_top">See
LbxSendTagDataEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxListenToOne</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
client</em></span>
: CARD32 or <span class="emphasis"><em>
0xffffffff</em></span>
</td></tr></tbody></table></div><p>
When the server is grabbed, <span class="emphasis"><em>
ListenToOne</em></span>
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.
</p><p>
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.
</p><p>
When the client grabbing the server is not managed through the proxy, the
client field in the event will be <span class="emphasis"><em>
0xffffffff</em></span>
. 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.
</p><p>
The server will send <span class="emphasis"><em>
ListenToAll</em></span>
to the proxy when the server is ungrabbed. There is no time-out for this
interval in the protocol.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#18630" target="_top">See The
description of this event is on page 27.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td class="protoname" align="left">LbxListenToAll</td></tr></tbody></table></div><p>
Notify the proxy that the server has been ungrabbed, and that the proxy may now
send all buffered client requests on to the server.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#30610" target="_top">See The
description of this event is on page 27.</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxQuickMotionDeltaEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaTime</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaX</em></span>
: INT8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaY</em></span>
: INT8</td></tr></tbody></table></div><p>
This event is used as a replacement for the <span class="emphasis"><em>
MotionNotify</em></span>
event when possible. The fields are used as deltas to the most recent
<span class="emphasis"><em>
MotionNotify</em></span>
event encoded as a <span class="emphasis"><em>
MotionNotify</em></span>
event, <span class="emphasis"><em>
LbxQuickMotionDeltaEvent</em></span>
, or <span class="emphasis"><em>
LbxMotionDeltaEvent</em></span>
. Not every <span class="emphasis"><em>
MotionNotify</em></span>
event can be encoded as a <span class="emphasis"><em>
LbxQuickMotionDeltaEvent</em></span>
.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#35213" target="_top">See
LbxQuickMotionDeltaEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxMotionDeltaEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaX</em></span>
: INT8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaY</em></span>
: INT8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaTime</em></span>
: CARD16</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
deltaSequence</em></span>
: CARD16</td></tr></tbody></table></div><p>
This event is used as a replacement for the <span class="emphasis"><em>
MotionNotify</em></span>
event when possible. The fields are used as deltas to the most recent
<span class="emphasis"><em>
MotionNotify</em></span>
event encoded as a <span class="emphasis"><em>
MotionNotify</em></span>
event, <span class="emphasis"><em>
LbxQuickMotionDeltaEvent</em></span>
, or <span class="emphasis"><em>
LbxMotionDeltaEvent</em></span>
. Not every <span class="emphasis"><em>
MotionNotify</em></span>
event can be encoded as <span class="emphasis"><em>
a LbxMotionDeltaEvent</em></span>
.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#35310" target="_top">See
LbxMotionDeltaEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxReleaseCmapEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
colormap</em></span>
: Colormap</td></tr></tbody></table></div><p>
This event notifies the proxy that it must release the grab on this colormap
via the ReleaseCmap request. <a class="ulink" href="lbx.htm#34675" target="_top">See
LbxReleaseCmap</a>
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#14052" target="_top">See
LbxReleaseCmapEvent</a>.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxFreeCellsEvent</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
colormap</em></span>
: Colormap</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
pixelStart, pixelEnd</em></span>
: CARD32</td></tr></tbody></table></div><p>
The <span class="emphasis"><em>
LbxFreeCells</em></span>
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. <a class="ulink" href="lbx.htm#10922" target="_top">See LbxGrabCmap</a>
</p><p>
The pixelStart and pixelEnd fields of the event denote a continuous range of
cells that were freed.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#14731" target="_top">See
LbxFreeCellsEvent</a>.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="responses"></a>Responses</h3></div></div></div><p>
Responses are messages from the server to the proxy that not, strictly
speaking, events, replies or errors.
</p><div class="proto"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><thead><tr><th class="protoname" align="left">LbxDeltaResponse</th></tr></thead><tbody><tr><td class="protoargs" align="left"><span class="emphasis"><em>
count</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
cache-index</em></span>
: CARD8</td></tr><tr><td class="protoargs" align="left"><span class="emphasis"><em>
diffs</em></span>
: LISTofDIFFITEM</td></tr></tbody></table></div><p>
This response carries an event, reply, or error that has been encoded relative
to a message in the response delta cache. The <span class="emphasis"><em>
cache-index</em></span>
field is the index into the cache. Each entry in <span class="emphasis"><em>
diffs</em></span>
provides a byte offset and replacement value to use in reconstructing the
response.
</p><p>
The encoding for this event is on <a class="ulink" href="lbx.htm#17100" target="_top">See
LbxDeltaResponse</a>.
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="algorithm_naming"></a>Algorithm Naming</h2></div></div></div><p>
To avoid potential clashes between different but similar algorithms for stream,
bitmap, and pixmap compression, the following naming scheme will be adhered to:
</p><p>
Each algorithm has a unique name, which is a STRING8, of the following form:
</p><p>
<organization>-<some-descriptive-name>
</p><p>
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.
</p><p>
As an example, the X Consortium defines a zlib-based stream compression
algorithm called XC-ZLIB.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="encoding"></a>Encoding</h2></div></div></div><p>
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.
</p><p>
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.
</p><p>
For unused bytes, the encode-form is:
</p><div class="literallayout"><p><br />
N unused<br />
</p></div><p>
If the number of unused bytes is variable, the encode-form typically is:
</p><div class="literallayout"><p><br />
p unused, p=pad(E)<br />
</p></div><p>
where E is some expression, and pad(E) is the number of bytes needed to round E
up to a multiple of four.
</p><p>
pad(E) = (4 - (E mod 4)) mod 4
</p><p>
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.
</p><div class="literallayout"><p><br />
For counted lists there is a common encoding of NLISTofFOO:<br />
</p></div><pre class="literallayout">
<span class="bold"><strong>NLISTofFOO</strong></span>
1 m num items
m LISTofFOO items
</pre><p>
For cached GC and Drawables:
</p><div class="literallayout"><p><br />
<span class="bold"><strong>LBXGCANDDRAWUPDATE</strong></span><br />
4 or 0 DRAWBLE optional drawable<br />
4 or 0 GC optional GC<br />
</p></div><div class="literallayout"><p><br />
<span class="bold"><strong>LBXGCANDDRAWABLE</strong></span><br />
8 LBXGCANDDRAWENT cache-entries<br />
8 unused<br />
m LBXGCANDDRAWUPDATE optional GC and Drawable<br />
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="errors2"></a>Errors</h3></div></div></div><pre class="literallayout">
<span class="bold"><strong>LbxClient</strong></span>
1 0 Error
1 CARD8 error-base + 0
2 CARD16 sequence number
4 unused
2 CARD16 lbx opcode
1 CARD8 major opcode
21 unused
</pre></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="requests2"></a>Requests</h3></div></div></div><pre class="literallayout">
<span class="bold"><strong>LbxQueryVersion</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#18761" target="_top">See
LbxQueryVersion</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxStartProxy</strong></span>
1 CARD8 opcode
1 1 lbx opcode
2 L request length
n NLISTofOPTION-REQUEST options
p unused, p=pad(n)
<span class="bold"><strong>OPTION-REQUEST</strong></span>
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
</pre><p>
The encoding of the option field depends on the option-code.
See <a class="ulink" href="lbx.htm#35444" target="_top">See StartProxy Options</a>.
</p><pre class="literallayout">
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
</pre><p>
OPTLEN has two possible encodings, depending on the size of the value carried:
</p><pre class="literallayout">
<span class="bold"><strong>OPTLEN</strong></span>
1 CARD8 b (0 < b <= 255)
<span class="bold"><strong>OPTLEN</strong></span>
1 0 long length header
1 c length0, c = b >> 8
1 d length1, d= b & #xff
<span class="bold"><strong>DELTAOPT</strong></span>
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
<span class="bold"><strong>NAMEDOPT</strong></span>
f STR type-name
1 g+1 option-data-length
g LISTofBYTE option-data (option specific)
<span class="bold"><strong>PIXMAPMETHOD</strong></span>
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)
<span class="bold"><strong>CHOICE</strong></span>
1 CARD8 request-option-index
b OPTLEN reply-option-byte-length
c DELTACHOICE or choice
INDEXEDCHOICE or
NLISTofINDEXEDOPT or
NLISTofPIXMAPCHOICE or
BOOL or
INDEXEDCHOICE
</pre><p>
The encoding of the choice field depends on the option-code. See <a class="ulink" href="lbx.htm#35444" target="_top">See StartProxy Options</a>.
</p><pre class="literallayout">
<span class="bold"><strong>DELTACHOICE</strong></span>
1 CARD8 preferred cache size
1 CARD8 preferred message length in 4-byte units
<span class="bold"><strong>INDEXEDCHOICE</strong></span>
1 CARD8 index
d LISTofBYTE data
<span class="bold"><strong>PIXMAPCHOICE</strong></span>
1 CARD8 index
1 CARD8 opcode
1 BITMASK format mask
e NLISTofCARD8 depths
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#20870" target="_top">See
LbxStartProxy</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxStopProxy</strong></span>
1 CARD8 opcode
1 2 lbx opcode
2 1 request length
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#27455" target="_top">See
LbxStopProxy</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxSwitch</strong></span>
1 CARD8 opcode
1 3 lbx opcode
2 2 request length
4 CARD32 client
</pre><p>
The description of this request is on
<a class="ulink" href="lbx.htm#33500" target="_top">See LbxSwitch</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxNewClient</strong></span>
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
</pre><p>
The remaining bytes depend on the value of change-type and length.
</p><p>
For no-deltas, the remaining bytes are the "additional data"
bytes of the core reply. (a = length of core reply, in 4 byte quantities).
</p><p>
For normal-client-deltas, the additional bytes have the form, with a length (a
= 1 +b):
</p><pre class="literallayout">
4 CARD32 resource id base
4b LISTofSETofEVENT root input masks
</pre><p>
For app-group-deltas, the additional bytes have the following form, with a
length of (a = 1 + 4c):
</p><pre class="literallayout">
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
</pre><p>
The description of this request is on
<a class="ulink" href="lbx.htm#17810" target="_top">See LbxNewClient</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxCloseClient</strong></span>
1 CARD8 opcode
1 5 lbx opcode
2 2 request length
4 CARD32 client
</pre><p>
The description of this request is on
<a class="ulink" href="lbx.htm#21625" target="_top">See LbxCloseClient</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxModifySequence</strong></span>
1 CARD8 opcode
1 6 lbx opcode
2 2 request length
4 CARD32 offset to sequence number
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#36693" target="_top">See
LbxModifySequence</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxAllowMotion</strong></span>
1 CARD8 opcode
1 7 lbx opcode
2 2 request length
4 CARD32 number of MotionNotify events
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#15895" target="_top">See
LbxAllowMotion</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxIncrementPixel</strong></span>
1 CARD8 opcode
1 8 lbx opcode
2 3 request length
4 COLORMAP colormap
4 CARD32 pixel
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#27227" target="_top">See
LbxIncrementPixel</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxDelta</strong></span>
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)
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#26857" target="_top">See
LbxDelta</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGetModifierMapping</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#37687" target="_top">See
LbxGetModifierMapping</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxInvalidateTag</strong></span>
1 CARD8 opcode
1 12 lbx opcode
2 2 request length
4 CARD32 tag
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#12515" target="_top">See
LbxInvalidateTag</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyPoint</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#37179" target="_top">See
LbxPolyPoint</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyLine</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#16574" target="_top">See
LbxPolyLine</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolySegment</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#26077" target="_top">See
LbxPolySegment</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyRectangle</strong></span>
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)
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#40958" target="_top">See
LbxPolyRectangle</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyArc</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#15317" target="_top">See
LbxPolyArc</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxFillPoly</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#35796" target="_top">See
LbxFillPoly</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyFillRectangle</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#25511" target="_top">See
LbxPolyFillRectangle</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyFillArc</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#42698" target="_top">See
LbxPolyFillArc</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGetKeyboardMapping</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#33719" target="_top">See
LbxGetKeyboardMapping</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxQueryFont</strong></span>
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 <span class="emphasis"><em>LeftToRight</em></span>
1 <span class="emphasis"><em>RightToLeft</em></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#18818" target="_top">See
LbxQueryFont</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxChangeProperty</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#40098" target="_top">See
LbxChangeProperty</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGetProperty</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#31397" target="_top">See
LbxGetProperty</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxTagData</strong></span>
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)
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#17987" target="_top">See
LbxTagData</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxCopyArea</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#11409" target="_top">See
LbxCopyArea</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxCopyPlane</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#36772" target="_top">See
LbxCopyPlane</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyText8</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#23201" target="_top">See
LbxPolyText8</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPolyText16</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#13228" target="_top">See
LbxPolyText16</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxImageText8</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#10990" target="_top">See
LbxImageText8</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxImageText16</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#39584" target="_top">See
LbxImageText16</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxQueryExtension</strong></span>
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)
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#36662" target="_top">See
LbxQueryExtension</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxPutImage</strong></span>
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
</pre><p>
If there is no left padding and the depth is less than or equal to nine,
PIPPACKED is encoded as follows:
</p><pre class="literallayout">
<span class="bold"><strong>PIPACKED</strong></span>
1 #x80 | (format << 5) | ((depth -1) << 2)
</pre><p>
Otherwise PIPACKED is defined as:
</p><pre class="literallayout">
<span class="bold"><strong>PIPACKED</strong></span>
1 (depth -1) << 2)
1 (format << 5) | left-pad
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#21218" target="_top">See
LbxPutImage</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGetImage</strong></span>
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)
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#26896" target="_top">See
LbxGetImage</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxBeginLargeRequest</strong></span>
1 CARD8 opcode
1 35 lbx opcode
2 2 request length
4 CARD32 large request length
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#31209" target="_top">See
LbxBeginLargeRequest</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxLargeRequestData</strong></span>
1 CARD8 opcode
1 36 lbx opcode
2 1+n request length
4n LISTofBYTE data
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#36982" target="_top">See
LbxLargeRequestData</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxEndLargeRequest</strong></span>
1 CARD8 opcode
1 37 lbx opcode
2 1 request length
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#31841" target="_top">See
LbxEndLargeRequest</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxInternAtoms</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#21636" target="_top">See
LbxInternAtoms</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGetWinAttrAndGeom</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#39382" target="_top">See
LbxGetWinAttrAndGeom</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxGrabCmap</strong></span>
1 CARD8 opcode
1 40 lbx opcode
2 2 request length
4 COLORMAP colormap
=>
</pre><p>
If smart-grab is true, the reply is as follows:
</p><pre class="literallayout">
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)
<span class="bold"><strong>CHANNELS</strong></span>
a CHAN red
1 5 next channel
b CHAN green
1 5 next channel
c CHAN blue
1 0 list end
<span class="bold"><strong>CHAN</strong></span>
d LISTofLBXPIXEL
<span class="bold"><strong>LBXPIXEL</strong></span>
e PIXELPRIVATE or
PIXELPRIVATERANGE or
PIXELALLOC or
PIXELALLOCRANGE
<span class="bold"><strong>PIXELPRIVATE</strong></span>
1 1 pixel-private
f PIXEL pixel
<span class="bold"><strong>PIXEL</strong></span>
f CARD8 or CARD16 (CARD8 if !two-byte-pixels)
<span class="bold"><strong>PIXELPRIVATERANGE</strong></span>
1 2 pixel-private-range
f PIXEL fist-pixel
f PIXEL last-pixel
<span class="bold"><strong>PIXELALLOC</strong></span>
1 3 pixel-private
f PIXEL pixel
g COLORSINGLE or COLORTRIPLE color (COLORSINGLE if
three-channels)
<span class="bold"><strong>COLORSINGLE</strong></span>
h CARD8 or CARD16 value (CARD8 if bits-per-rgb =< 7)
<span class="bold"><strong>COLORTRIPLE</strong></span>
h COLORSINGLE red
h COLORSINGLE green
h COLORSINGLE blue
<span class="bold"><strong>PIXELALLOCRANGE</strong></span>
1 4 pixel-private
f PIXEL first-pixel
f PIXEL last-pixel
j LISTofCOLORSINGLE or color (COLORSINGLE if three-channels)
LISTofCOLORTRIPLE
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#10922" target="_top">See
LbxGrabCmap</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxReleaseCmap</strong></span>
1 CARD8 opcode
1 41 lbx opcode
2 2 request length
4 COLORMAP cmap
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#34675" target="_top">See
LbxReleaseCmap</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxAllocColor</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#10446" target="_top">See
LbxAllocColor</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxSync</strong></span>
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
</pre><p>
The description of this request is on <a class="ulink" href="lbx.htm#30719" target="_top">See
LbxSync</a>.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="events2"></a>Events</h3></div></div></div><pre class="literallayout">
<span class="bold"><strong>LbxSwitchEvent</strong></span>
1 base + 0 code
1 0 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#33748" target="_top">See
LbxSwitchEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxCloseEvent</strong></span>
1 base + 0 code
1 1 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#17292" target="_top">See
LbxCloseEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxInvalidateTagEvent</strong></span>
1 base + 0 code
1 3 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
1 <span class="emphasis"><em>LbxTagTypeModmap</em></span>
2 <span class="emphasis"><em>LbxTagTypeKeymap</em></span>
3 <span class="emphasis"><em>LbxTagTypeProperty</em></span>
4 <span class="emphasis"><em>LbxTagTypeFont</em></span>
5 <span class="emphasis"><em>LbxTagTypeConnInfo</em></span>
20 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#23016" target="_top">See
LbxInvalidateTagEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxSendTagDataEvent</strong></span>
1 base + 0 code
1 4 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
3 <span class="emphasis"><em>LbxTagTypeProperty</em></span>
20 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#20373" target="_top">See
LbxSendTagDataEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxListenToOne</strong></span>
1 base + 0 code
1 5 lbx type
2 CARD16 sequence number
4 CARD32 client
<span class="emphasis"><em>#xFFFFFFFF</em></span>
a client not managed by the proxy
24 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#25209" target="_top">See
LbxListenToOne</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxListenToAll</strong></span>
1 base + 0 code
1 6 lbx type
2 CARD16 sequence number
28 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#11095" target="_top">See
LbxListenToAll</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxQuickMotionDeltaEvent</strong></span>
1 base + 1 code
1 CARD8 delta-time
1 INT8 delta-x
1 INT8 delta-y
</pre><p>
This event is not padded to 32 bytes.
</p><p>
The description of this event is on <a class="ulink" href="lbx.htm#40268" target="_top">See
LbxQuickMotionDeltaEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxMotionDeltaEvent</strong></span>
1 base + 0 code
1 7 lbx type
1 INT8 delta-x
1 INT8 delta-y
2 CARD16 delta-time
2 CARD16 delta-sequence
</pre><p>
This event is not padded to 32 bytes.
</p><p>
The description of this event is on <a class="ulink" href="lbx.htm#30033" target="_top">See
LbxMotionDeltaEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxReleaseCmapEvent</strong></span>
1 base + 0 code
1 8 lbx type
2 CARD16 sequence number
4 COLORMAP colormap
24 unused
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#19129" target="_top">See
LbxReleaseCmapEvent</a>.
</p><pre class="literallayout">
<span class="bold"><strong>LbxFreeCellsEvent</strong></span>
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
</pre><p>
The description of this event is on <a class="ulink" href="lbx.htm#38041" target="_top">See
LbxFreeCellsEvent</a>.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="re_encoding_of_x_events"></a>Re-encoding of X Events</h3></div></div></div><p>
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.
</p><p>
LBX reencodes X event representations into the following sizes, if squishing is
enabled:
</p><pre class="programlisting">
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
</pre></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="responses2"></a>Responses</h3></div></div></div><pre class="literallayout">
<span class="bold"><strong>LbxDeltaResponse</strong></span>
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)
</pre><p>
The description of this response is on <a class="ulink" href="lbx.htm#34042" target="_top">See
LbxDeltaResponse</a>.
</p></div></div></div></body></html>
Copyright © 2017 || Recoded By Mr.Bumblebee