X Version 11, Release 7.6
Version 7.1
Copyright © 1996 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.
X Window System is a trademark of The OpenGroup.
November 15, 1996
Table of Contents
The Security extension contains new protocol needed to provide enhanced X server security. The Security extension should not be exposed to untrusted clients (defined below).
This request returns the major and minor version numbers of this extension.
SecurityQueryVersion
|
client-major-version |
CARD16 |
|
client-minor-version |
CARD16 |
|
=> | |
|
server-major-version |
CARD16 |
|
server-minor-version |
CARD16 |
The client-major-version and client-minor-version numbers indicate what version of the protocol the client wants the server to implement. The server-major-version and the server-minor-version numbers returned indicate the protocol this extension actually supports. This might not equal the version sent by the client. An implementation can (but need not) support more than one version simultaneously. The server-major-version and server-minor-version allow the creation of future revisions of the Security protocol that may be necessary. In general, the major version would increment for incompatible changes, and the minor version would increment for small, upward-compatible changes. Servers that support the protocol defined in this document will return a server-major-version of one (1), and a server-minor-version of zero (0).
Clients using the Security extension must issue a SecurityQueryVersion request before any other Security request in order to negotiate a compatible protocol version; otherwise, the client will get undefined behavior (Security may or may not work).
This request causes the server to create and return a new authorization with specific characteristics. Clients can subsequently connect using the new authorization and will inherit some of the characteristics of the authorization.
SecurityGenerateAuthorization
|
authorization-protocol-name |
STRING8 |
|
authorization-protocol-data |
STRING8 |
|
value-mask |
BITMASK |
|
value-list |
LISTofVALUE |
|
=> | |
|
authorization-id |
AUTHID |
|
authorization-data-return |
STRING8 |
Errors: AuthorizationProtocol, Value, Alloc
authorization-protocol-name is the name of the authorization method for which the server should generate a new authorization that subsequent clients can use to connect to the server. If the authorization-protocol-name is not one that the server supports, or if authorization-protocol-data does not make sense for the given authorization-protocol-name, an AuthorizationProtocol error results.
authorization-protocol-data is authorization-method specific data that can be used in some way to generate the authorization.
In this version of the extension, the only authorization method required to be supported is "MIT-MAGIC-COOKIE-1" with any amount of authorization-protocol-data (including none). The server may use the authorization-protocol-data as an additional source of randomd="left" valign="top" />
display
Specifies the connection to the X server.
major_version_return
Returns the major version supported by the server.
minor_version_return
Returns the minor version supported by the server.
XCupQueryVersions sets major_version_return and minor_version_return to the major and minor TOG-CUP protocol version supported by the server. If the TOG-CUP library is compatible with the version returned by the server, it returns nonzero. If dpy does not support the TOG-CUP extension, or if there was an error during communication with the server, or if the server and library protocol versions are incompatible, it returns zero. No other XCup functions may be called before this function. If a client violates this rule, the effects of all subsequent XCup calls that it makes are undefined.
To get the list of reserved colormap entries, use XCupGetReservedColormapEntries.
Status fsfunc XCupGetReservedColormapEntries(Display* display, int screen, XColor** colors_out, int* ncolors);
display | Specifies the connection to the X server. |
colors_out | Returns the values reserved by the server. |
ncolors | Returns the number of items in colors_out. |
The XCupGetReservedColormapEntries function gets system specific colormap entries. E.g. the MS-Windows desktop uses N colormap entries at the beginning (0..N) and end (256-N..255) of the colormap. Use XFree to free colors_out.
To allocate one or more read-only color cells with RGB values, use XCupStoreColors.
Status fsfunc XCupStoreColors(Display* display, Colormap colormap, XColor* colors_in_out, int ncolors);
display | Specifies the connection to the X server. |
colormap | Specifies the colormap. |
colors_in_out | Specifies and returns the values actually used in the colormap. |
ncolors | Specifies the number of items in colors_in_out. |
The XCupStoreColors function changes the colormap entries of the pixel values specified in the pixel members of the XColor structures. The colormap entries are allocated as if an AllocColor had been used instead, i.e. the colors are read-only (shareable). XCupStoreColors returns the number of colors that were successfully allocated in the colormap.
The X server preallocates any hardware or desktop special colors in the default colormap; e.g. UNIX X servers preallocate Black and White pixels. PC X servers should also preallocate the MS-Windows desktop colors. (Note to implementors: in the Sample Implementation special colors are allocated in the default colormap in cfbCreateDefColormap for dumb memory framebuffers.)
To minimize colormap flash an application which installs its own private colormap should query the special colors by calling XCupGetReservedColormapEntries, and can then store those entries (in the proper location) in its private colormap using XCupStoreColors.
Applications which allocate many colors in a screen's default colormap, e.g. a color-cube or a gray-ramp, should allocate them with XCupStoreColors. By using XCupStoreColors the colors will be allocated sharable (read-only) and any other application which allocates the same color will share that color cell.