diff options
author | Alan Coopersmith <alan.coopersmith@oracle.com> | 2010-06-11 18:47:23 -0700 |
---|---|---|
committer | Alan Coopersmith <alan.coopersmith@oracle.com> | 2010-06-11 18:47:23 -0700 |
commit | 675ca9abbc38f088b177a67501ab5eff1c9dcff5 (patch) | |
tree | 44b487494fa7d835c0bb3db9f70eff9fcebe2663 /specs | |
parent | 72cc123fbf3b5186771529cd5d9d9af46470b1af (diff) | |
download | xorg-lib-libXext-675ca9abbc38f088b177a67501ab5eff1c9dcff5.tar.gz |
Move specs for several extension API's from xorg-docs module
Not formatted, translated or processed yet, just moved & added to EXTRA_DIST
Only moved those that had separate library/API docs from the protocol specs.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Diffstat (limited to 'specs')
-rw-r--r-- | specs/DPMSLib.ms | 331 | ||||
-rw-r--r-- | specs/Makefile.am | 5 | ||||
-rw-r--r-- | specs/dbelib.tex | 621 | ||||
-rw-r--r-- | specs/shapelib.ms | 556 | ||||
-rw-r--r-- | specs/synclib.tex | 773 |
5 files changed, 2286 insertions, 0 deletions
diff --git a/specs/DPMSLib.ms b/specs/DPMSLib.ms new file mode 100644 index 0000000..a8e909c --- /dev/null +++ b/specs/DPMSLib.ms @@ -0,0 +1,331 @@ +.\" Use -ms and macros.t +.\" $XdotOrg: xc/doc/specs/Xext/DPMSLib.ms,v 1.2 2004/04/23 18:42:18 eich Exp $ +.EH '''' +.OH '''' +.EF '''' +.OF '''' +.ps 10 +.nr PS 10 +\& +.sp 8 +.ce 1 +\s+2\fBX Display Power Management Signaling (DPMS) Extension\fP\s-2 +.sp +.ce 1 +\s+1\fBLibrary Specification\fP\s-1 +.sp 3 +.ce 3 +Version 1.0 +X Project Team Standard +X Version 11, Release 6.8 +.sp 6 +.ce 4 +Rob Lembree +\fIlembree@zk3.dec.com\fP +.sp 6p +Digital Equipment Corporation +.sp 6p +24 April 1996 +.ps 9 +.nr PS 9 +.sp 8 +.LP +.bp +.sp 15 +Copyright \(co Digital Equipment Corporation, 1996 +.LP +Permission to use, copy, modify, distribute, and sell this +documentation for any purpose is hereby granted without fee, +provided that the above copyright notice and this permission +notice appear in all copies. Digital Equipment Corporation +makes no representations about the suitability for any purpose +of the information in this document. This documentation is +provided ``as is'' without express or implied warranty. +.LP +.ps 10 +.nr PS 10 +.bp 1 +.EH '\fBDisplay Power Management Signaling (DPMS) Extension\fP' +.OH '\fBDisplay Power Management Signaling (DPMS) Extension\fP' +.EF ''\fB % \fP'' +.OF ''\fB % \fP'' +.NH 1 +Overview +.LP +This extension provides X Protocol control over the VESA Display +Power Management Signaling (DPMS) characteristics of video boards +under control of the X Window System. +.FS +1. \fIX Window System\fP is a trademark of The Open Group. +.FE +.LP +Traditionally, the X Window System has provided for both blanking and +non-blanking screen savers. Timeouts associated with these built-in +screen saver mechanisms are limited to idle (dwell) time, and a change +timeout that specifies the change interval for non-blanking screen savers. +.LP +The United States' Environmental Protection Agency (EPA) Energy Star program +requires that monitors power down after some idle time by default. +While it is possible to simply overload the existing screen saver timeouts, +this solution leaves the non-privileged user little to no control over +the DPMS characteristics of his or her system. For example, disabling +DPMS would require some unintended side effect in the core screen saver, +such as disabling the changing of a non-blanking screen saver. Providing +clients with this control requires an extension to the core X Window System +Protocol, and this extension seeks to fill this gap. +.LP +There are four power levels specified by the Video Electronics Standards +Association (VESA) Display Power Management Signaling (DPMS) standard. +These are mapped onto the X DPMS Extension like this: +.LP +.Ds 0 +.TA .2i 1.5i 2.5i 3.5i +.ta .2i 1.5i 2.5i 3.5i +.R +.PN "DPMS Extension Power Levels" + 0 DPMSModeOn In use + 1 DPMSModeStandby Blanked, low power + 2 DPMSModeSuspend Blanked, lower power + 3 DPMSModeOff Shut off, awaiting activity +.De + +.NH 1 +DPMS Functions + +.PN DPMSQueryExtension +.LP + +Bool DPMSQueryExtension \^(\fIdisplay, event_base, error_base\fP\^) +.IP + Display \fI*display;\fP +.br + int \fI*event_base, *error_base;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fIevent_base\fP Specifies the return location for the assigned base event +.br +\fIerror_base\fP Specifies the return location for the assigned base error + +.LP +The DPMSQueryExtension function queries the X server to determine the availability +of the DPMS Extension. If the extension is available, the return value is TRUE, +and \fIevent_base\fP and \fIerror_base\fP are set to the base event number and base +error number for the extension, respectively. Otherwise, the return value is +FALSE, and the values of \fIevent_base\fP and \fIerror_base\fP are undefined. +.LP + +.PN DPMSGetVersion +.LP + +Status DPMSGetVersion\^(\fIdisplay, major_version, minor_version\fP\^) +.IP + Display \fI*display;\fP +.br + int \fI*major_version, *minor_version;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fImajor_version\fP Specifies the return location for the extension major version. +.br +\fIminor_version\fP Specifies the return location for the extension minor version. + +.LP +The DPMSGetVersion function returns the version of the DPMS extension implemented by +the X server. The version is returned in \fImajor_version\fP and \fIminor_version\fP. +The major version and minor version for this specification are '1' and '1', respectively. +The major version will be incremented for protocol incompatible changes, and the minor +version will be incremented for small, upwardly compatible changes. +.LP + +.PN DPMSCapable +.LP + +Bool DPMSCapable\^(\fIdisplay\fP\^) +.IP + Display \fI*display;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. + +.LP +The DPMSCapable function returns the DPMS capability of the X server, either +TRUE \^(capable of DPMS\^) or FALSE \^(incapable of DPMS\^). The capability +of an X server is implementation defined. For example, if a multi-headed X server +is capable of DPMS on one head, and incapable on another, the truth value of this +function is defined by the X server implementation. +.LP + +.PN DPMSSetTimeouts +.LP + + +Status DPMSSetTimeouts\^(\fIdisplay, standby, suspend, off\fP\^) +.IP + Display \fI*display;\fP +.br + CARD16 \fIstandby, suspend, off;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fIstandby\fP Specifies the new standby timeout in seconds. +.br +\fIsuspend\fP Specifies the new suspend timeout in seconds. +.br +\fIoff\fP Specifies the new off timeout in seconds. + +.LP +The DPMSSetTimeouts function permits applications to set the timeout values +used by the X server for DPMS timings. +.LP +The value \fIstandby\fP is the amount of time of inactivity in seconds before +standby mode is invoked. The actual effects of this mode are implementation +defined, but in the case of DPMS compliant hardware, it is implemented by +shutting off the horizontal sync signal, and pulsing the vertical sync signal. +Standby mode provides the quickest monitor recovery time. Note also that many +monitors implement this mode identically to suspend mode. A value of zero +disables this mode. +.LP +The value \fIsuspend\fP is the amount of time of inactivity in seconds +before the second level of power savings is invoked. Suspend mode's physical +and electrical characteristics are implementation defined, but in DPMS compliant +hardware, results in the pulsing of the horizontal sync signal, and shutting off +of the vertical sync signal. Suspend mode recovery is considered to be slower +than standby mode, but faster than off mode, however this is monitor +dependent. As noted above, many monitors implement this mode identically to +standby mode. A value of zero disables this mode. +.LP +The value \fIoff\fP is the amount of time of inactivity in seconds before the third and +final level of power savings is invoked. Off mode's physical and electrical +characteristics are implementation defined, but in DPMS compliant hardware, +is implemented by shutting off both horizontal and vertical sync signals, +resulting in the power-down of the monitor. Recovery time is implementation +dependant, but frequently is similar to the power-up time of the monitor. +A value of zero disables this mode. +.LP +Chronologically, standby mode occurs before or simultaneously with suspend mode, and +suspend mode must occur before or simultaneously with off mode. Therefore, +non-zero mode timeout values must be greater than or equal to the timeout values of +earlier modes. If inconsistent values are supplied, a BadValue error will result. +.LP + +.PN DPMSGetTimeouts +.LP + + +Bool DPMSGetTimeouts\^(\fIdisplay, standby, suspend, off\fP\^) +.IP + Display \fI*display;\fP +.br + CARD16 \fI*standby, *suspend, *off;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fIstandby\fP Specifies the current standby timeout in seconds. +.br +\fIsuspend\fP Specifies the current suspend timeout in seconds. +.br +\fIoff\fP Specifies the current off timeout in seconds. + +.LP +The DPMSGetTimeouts function retrieves the timeout values used by the X +server for DPMS timings. +.LP +The value \fIstandby\fP is the amount of time of inactivity in seconds before +standby mode is invoked. A value of zero indicates that this mode has been disabled. +.LP +The value \fIsuspend\fP is the amount of time of inactivity in seconds before the +second level of power savings is invoked. A value of zero indicates that this mode +has been disabled. +.LP +The value \fIoff\fP is the amount of time of inactivity in seconds before the third +and final level of power savings is invoked. A value of zero indicates that this mode +has been disabled. +.LP + +.PN DPMSEnable +.LP + + +Status DPMSEnable\^(\fIdisplay\fP\^) +.IP + Display \fI*display;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. + +.LP +The DPMSEnable function enables DPMS on the specified display. When +enabled, DPMS will use the currently saved timeout values, and will +invoke the DPMS power mode appropriate for the amount of time that +the workstation input devices have been idle. If DPMSEnable is invoked +on a display with DPMS already enabled, no change is made, and no +error is returned. If DPMSEnable is invoked on a display without +support for DPMS, no change is made and no error is returned. +.LP + +.PN DPMSDisable +.LP + + +Status DPMSDisable\^(\fIdisplay\fP\^) +.IP + Display \fI*display;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. + +.LP +The DPMSDisable function disables DPMS on the specified display. When +disabled, DPMS returns the display to DPMSModeOn. If DPMSDisable is +invoked on a display with DPMS already disabled, no change is made, +and no error is returned. If DPMSDisable is invoked on a display +without support for DPMS, no change is made and no error is returned. +.LP + +.PN DPMSForceLevel +.LP + + +Status DPMSForceLevel\^(\fIdisplay, level\fP\^) +.IP + Display \fI*display;\fP +.br + CARD16 \fIlevel;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fIlevel\fP Specifies the level to force power to. + +.LP +The DPMSForceLevel function forces a DPMS capable display into the +specified power level. The \fIlevel\fP must be one of +DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, or DPMSModeOff. +Values other than these will result in a BadValue error. If DPMS +is disabled on the display, a BadMatch protocol error will result. +.LP + +.PN DPMSInfo +.LP + + +Status DPMSInfo\^(\fIdisplay, power_level, state\fP\^) +.IP + Display \fI*display;\fP +.br + CARD16 \fI*power_level;\fP +.br + BOOL \fI*state;\fP +.LP +\fIdisplay\fP Specifies the connection to the X server. +.br +\fIpower_level\fP Specifies the current power level. +.br +\fIstate\fP Specifies the current DPMS state + +.LP +The DPMSInfo function returns information about the current DPMS state. +The \fIstate\fP return parameter indicates whether or not DPMS is enabled +\^(TRUE\^) or +disabled \^(FALSE\^). The \fIpower_level\fP return parameter indicates the current +power level \^(one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, or +DPMSModeOff.\^) +.LP + diff --git a/specs/Makefile.am b/specs/Makefile.am new file mode 100644 index 0000000..a82d5a2 --- /dev/null +++ b/specs/Makefile.am @@ -0,0 +1,5 @@ +EXTRA_DIST = \ + dbelib.tex \ + DPMSLib.ms \ + shapelib.ms \ + synclib.tex diff --git a/specs/dbelib.tex b/specs/dbelib.tex new file mode 100644 index 0000000..4b9a076 --- /dev/null +++ b/specs/dbelib.tex @@ -0,0 +1,621 @@ +% $Xorg: dbelib.tex,v 1.3 2000/08/17 19:42:31 cpqbld Exp $ +% edited for DP edits and code consistency w/ core protocol/xlib 3/30/96 +% split into separate library and protocol documentos 4/15/96 +\documentstyle{article} +\pagestyle{myheadings} +\markboth{Double Buffer Extension Specification}{Double Buffer Extension Specification} +\setlength{\parindent}{0 pt} +\setlength{\parskip}{6pt} +\setlength{\topsep}{0 pt} + +% Request names are literal symbols; therefore, use the same font for both. +\newcommand{\requestname}[1]{{\tt #1}} +\newcommand{\literal}[1]{\mbox{\tt #1}} + +\newcommand{\encodingsection}[1]{{\bf #1}} +\newcommand{\requestsection}[1]{{\bf #1}} + +% Font treatment of type names differs between protocol and library sections. +\newcommand{\libtypename}[1]{\mbox{\tt #1}} +\newcommand{\typename}[1]{\mbox{\rm #1}} % default font +\newcommand{\typeargname}[1]{\mbox{\rm #1}} % default font +\newcommand{\argname}[1]{\mbox{\it #1}} +\newcommand{\argdecl}[2]{\argname{#1} & : \typename{#2}\\} +\newcommand{\areplyargdecl}[2]{#1 & : \typename{#2}\\} + +\newenvironment{arequest}[1]{\requestsection{#1} \\ \begin{tabular}{ll}}{\end{tabular}} +\newcommand{\areply}{$\Rightarrow$\\} + +\newcommand{\etabstops}{\hspace*{0cm}\=\hspace*{1cm}\=\hspace*{5cm}\=\kill} + +\newcommand{\eargdecl}[3]{\> #1 \> \typename{#2} \> #3 \\} + +\newenvironment{keeptogether}{\vbox \bgroup}{\egroup} + +\newenvironment{erequest}[3]{\pagebreak[3] \begin{keeptogether} \encodingsection{#1} \begin{tabbing} \etabstops \eargdecl{1}{CARD8}{major-opcode} \eargdecl{1}{#2}{minor-opcode} \eargdecl{2}{#3}{request length}}{\end{tabbing} \end{keeptogether}} + +\newenvironment{eerror}[1]{\begin{keeptogether} \encodingsection{#1} \begin{tabbing} \etabstops }{\end{tabbing} \end{keeptogether}} + +\newenvironment{etypedef}[1]{\begin{keeptogether} \typename{#1} \begin{tabbing} \etabstops }{\end{tabbing} \end{keeptogether}} + +\newcommand{\cfunctionname}[1]{\mbox{\tt #1}} +\newcommand{\cfunctiondecl}[1]{\mbox{\rm #1}} +\newcommand{\cargdecl}[2]{\penalty -1\typename{#1} \argname{#2}} +\newenvironment{cfunction}[2]{\begin{sloppypar}\begin{keeptogether}\vspace{5mm}\typename{#1}\\ \cfunctiondecl{#2}\ (}{)\end{keeptogether}\end{sloppypar}{\hangafter=2 \hangindent=20pt \raggedright\par}} + +% make things easier with all the long names +\spaceskip .3333em plus 5em +\tolerance=2000 + +\begin{document} + +\title{Double Buffer Extension Library\\Protocol Version 1.0\\X Consortium Standard} +\author{Ian Elliott\\Hewlett-Packard Company \and David P. Wiggins\\X Consortium, Inc.} +\maketitle +\thispagestyle{empty} + +\eject + +Copyright \copyright 1989 X Consortium, Inc. and Digital Equipment Corporation. + +Copyright \copyright 1992 X Consortium, Inc. and Intergraph Corporation. + +Copyright \copyright 1993 X Consortium, Inc. and Silicon Graphics, Inc. + +Copyright \copyright 1994, 1995 X Consortium, Inc. and Hewlett-Packard Company. + +Permission to use, copy, modify, and distribute this documentation for +any purpose and without fee is hereby granted, provided that the above +copyright notice and this permission notice appear in all copies. +Digital Equipment Corporation, Intergraph Corporation, Silicon +Graphics, Hewlett-Packard, and the X Consortium make no +representations about the suitability for any purpose of the +information in this document. This documentation is provided ``as is'' +without express or implied warranty. + +\eject + +\section{Introduction} + +The Double Buffer Extension (DBE) provides a standard way to utilize +double-buffering within the framework of the X Window System. +Double-buffering uses two buffers, called front and back, which hold +images. The front buffer is visible to the user; the back buffer is +not. Successive frames of an animation are rendered into the back +buffer while the previously rendered frame is displayed in the front +buffer. When a new frame is ready, the back and front buffers swap +roles, making the new frame visible. Ideally, this exchange appears to +happen instantaneously to the user and with no visual artifacts. Thus, +only completely rendered images are presented to the user, and they remain +visible during the entire time it takes to render a new frame. The +result is a flicker-free animation. + +\section{Goals} + +This extension should enable clients to: +\begin{itemize} + +\item Allocate and deallocate double-buffering for a window. + +\item Draw to and read from the front and back buffers associated with +a window. + +\item Swap the front and back buffers associated with a window. + +\item Specify a wide range of actions to be taken when a window is +swapped. This includes explicit, simple swap actions (defined +below), and more complex actions (for example, clearing ancillary buffers) +that can be put together within explicit ``begin'' and ``end'' +requests (defined below). + +\item Request that the front and back buffers associated with multiple +double-buffered windows be swapped simultaneously. + +\end{itemize} + +In addition, the extension should: + +\begin{itemize} + +\item Allow multiple clients to use double-buffering on the same window. + +\item Support a range of implementation methods that can capitalize on +existing hardware features. + +\item Add no new event types. + +\item Be reasonably easy to integrate with a variety of direct graphics +hardware access (DGHA) architectures. +\end{itemize} + +\section{Concepts} + +Normal windows are created using the core \requestname{CreateWindow} +request, which allocates a set of window attributes and, for +\literal{InputOutput} windows, a front buffer, +into which an image can be drawn. +The contents of this buffer will be displayed when the window is +visible. + +This extension enables applications to use double-buffering with a +window. This involves creating a second buffer, called a back buffer, +and associating one or more back buffer names (\typename{XID}s) with +the window for use when referring to (that is, drawing to or reading +from) the window's back buffer. The back buffer name is a +\typename{DRAWABLE} of type \typename{BACKBUFFER}. + +DBE provides a relative double-buffering model. One XID, the window, +always refers to the front buffer. One or more other XIDs, the back buffer +names, always refer to the back buffer. After a buffer swap, the +window continues to refer to the (new) front buffer, and the +back buffer name continues to refer to the (new) back buffer. Thus, +applications and toolkits that want to just render to the back buffer +always use the back buffer name for all drawing requests to the +window. Portions of an application that want to render to the front +buffer always use the window XID for all drawing requests to the +window. + +Multiple clients and toolkits can all use double-buffering on the same +window. DBE does not provide a request for querying whether a window +has double-buffering support, and if so, what the back buffer name is. +Given the asynchronous nature of the X Window System, this would cause +race conditions. Instead, DBE allows multiple back buffer names to +exist for the same window; they all refer to the same physical back +buffer. The first time a back buffer name is allocated for a window, +the window becomes double-buffered and the back buffer name is +associated with the window. Subsequently, the window already is a +double-buffered window, and nothing about the window changes when a +new back buffer name is allocated, except that the new back buffer +name is associated with the window. The window remains +double-buffered until either the window is destroyed or until all of +the back buffer names for the window are deallocated. + +In general, both the front and back buffers are treated the same. In +particular, here are some important characteristics: + +\begin{itemize} + +\item Only one buffer per window can be visible at a time (the +front buffer). + +\item Both buffers associated with a window have the same visual type, +depth, width, height, and shape as the window. + +\item Both buffers associated with a window are ``visible'' (or +``obscured'') in the same way. When an \literal{Expose} event is +generated for +a window, both buffers should be considered to be damaged in the +exposed area. Damage that occurs to either buffer will result in an +\literal{Expose} event on the window. When a double-buffered window is +exposed, +both buffers are tiled with the window background, exactly as stated +by the core protocol. Even though the back buffer is not visible, +terms such as obscure apply to the back buffer as well as to the front +buffer. + +\item It is acceptable at any time to pass a \typename{BACKBUFFER} in +any request, notably any core or extension drawing request, that +expects a \typename{DRAWABLE}. This enables an application to draw +directly into \typename{BACKBUFFER}s in the same fashion as it would +draw into any other \typename{DRAWABLE}. + +\item It is an error (\literal{Window}) to pass a \typename{BACKBUFFER} in a +core request that expects a Window. + +\item A \typename{BACKBUFFER} will never be sent by core X in a reply, +event, or error where a Window is specified. +\item If core X11 backing-store and save-under applies to a +double-buffered window, it applies to both buffers equally. + +\item If the core \requestname{ClearArea} request is executed on a +double-buffered window, the same area in both the front and back +buffers is cleared. + +\end{itemize} + +The effect of passing a window to a request that accepts a +\typename{DRAWABLE} is unchanged by this extension. The window and +front buffer are synonomous with each other. This includes obeying +the \requestname{GetImage} semantics and the subwindow-mode semantics +if a core graphics context is involved. Regardless of whether the +window was explicitly passed in a \requestname{GetImage} request, or +implicitly referenced (that is, one of the window's ancestors was passed +in the request), the front (that is, visible) buffer is always referenced. +Thus, DBE-na\"{\i}ve screen dump clients will always get the front buffer. +\requestname{GetImage} on a back buffer returns undefined image +contents for any obscured regions of the back buffer that fall within +the image. + +Drawing to a back buffer always uses the clip region that would be +used to draw to the front buffer with a GC subwindow-mode of +\literal{ClipByChildren}. If an ancestor of a double-buffered window is drawn +to with a core GC having a subwindow-mode of \literal{IncludeInferiors}, the +effect on the double-buffered window's back buffer depends on the +depth of the double-buffered window and the ancestor. If the depths +are the same, the contents of the back buffer of the double-buffered +window are not changed. If the depths are different, the contents of +the back buffer of the double-buffered window are undefined for the +pixels that the \literal{IncludeInferiors} drawing touched. + +DBE adds no new events. DBE does not extend the semantics of any +existing events with the exception of adding a new \typename{DRAWABLE} +type called \typename{BACKBUFFER}. If events, replies, or errors that +contain a \typename{DRAWABLE} (for example, \literal{GraphicsExpose}) are +generated in +response to a request, the \typename{DRAWABLE} returned will be the +one specified in the request. + +DBE advertises which visuals support double-buffering. + +DBE does not include any timing or synchronization facilities. +Applications that need such facilities (for example, to maintain a constant +frame rate) should investigate the Synchronization Extension, an X +Consortium standard. + +\subsection{Window Management Operations} + +The basic philosophy of DBE is that both buffers are treated the same by +core X window management operations. + +When the core \requestname{DestroyWindow} is executed on a +double-buffered window, both buffers associated with the window are +destroyed, and all back buffer names associated with the window are +freed. + +If the core \requestname{ConfigureWindow} request changes the size of +a window, both buffers assume the new size. If the window's size +increases, the effect on the buffers depends on whether the +implementation honors bit gravity for buffers. If bit gravity is +implemented, then the contents of both buffers are moved in accordance +with the window's bit gravity (see the core +\requestname{ConfigureWindow} request), and the remaining areas are +tiled with the window background. If bit gravity is not implemented, +then the entire unobscured region of both buffers is tiled with the +window background. In either case, \literal{Expose} events are generated for +the region that is tiled with the window background. + +If the core \requestname{GetGeometry} request is executed on a +\typename{BACKBUFFER}, the returned x, y, and border-width will be +zero. + +If the Shape extension \requestname{ShapeRectangles}, +\requestname{ShapeMask}, \requestname{ShapeCombine}, or +\requestname{ShapeOffset} request is executed on a double-buffered +window, both buffers are reshaped to match the new window shape. The +region difference is the following: + +\[ D = new shape - old shape \] + +It is tiled with the window background in both buffers, +and \literal{Expose} events are generated for D. + +\subsection{Complex Swap Actions} + +DBE has no explicit knowledge of ancillary buffers (for example, depth buffers +or alpha buffers), and only has a limited set of defined swap actions. +Some applications may need a richer set of swap actions than DBE +provides. Some DBE implementations have knowledge of ancillary +buffers, and/or can provide a rich set of swap actions. Instead of +continually extending DBE to increase its set of swap actions, DBE +provides a flexible ``idiom'' mechanism. If an application's needs +are served by the defined swap actions, it should use them; otherwise, +it should use the following method of expressing a complex swap action +as an idiom. Following this policy will ensure the best possible +performance across a wide variety of implementations. + +As suggested by the term ``idiom,'' a complex swap action should be +expressed as a group/series of requests. Taken together, this group +of requests may be combined into an atomic operation by the +implementation, in order to maximize performance. The set of idioms +actually recognized for optimization is implementation dependent. To +help with idiom expression and interpretation, an idiom must be +surrounded by two protocol requests: \requestname{DBEBeginIdiom} and +\requestname{DBEEndIdiom}. Unless this begin-end pair surrounds the +idiom, it may not be recognized by a given implementation, and +performance will suffer. + +For example, if an application wants to swap buffers for two windows, +and use core X to clear only certain planes of the back buffers, the +application would issue the following protocol requests as a group, and +in the following order: + +\begin{itemize} +\item \requestname{DBEBeginIdiom} request. +\item \requestname{DBESwapBuffers} request with XIDs for two windows, each +of which uses a swap action of \literal{Untouched}. +\item Core X \requestname{PolyFillRectangle} request to the back buffer of one window. +\item Core X \requestname{PolyFillRectangle} request to the back buffer of the other window. +\item \requestname{DBEEndIdiom} request. +\end{itemize} + +The \requestname{DBEBeginIdiom} and \requestname{DBEEndIdiom} requests +do not perform any actions themselves. They are treated as markers by +implementations that can combine certain groups/series of requests as +idioms, and are ignored by other implementations or for nonrecognized +groups/series of requests. If these requests are sent out of order, +or are mismatched, no errors are sent, and the requests are executed +as usual, though performance may suffer. + +An idiom need not include a \requestname{DBESwapBuffers} request. For +example, if a swap action of \literal{Copied} is desired, but only some of the +planes should be copied, a core X \requestname{CopyArea} request may +be used instead of \requestname{DBESwapBuffers}. If +\requestname{DBESwapBuffers} is included in an idiom, it should +immediately follow the \requestname{DBEBeginIdiom} request. Also, +when the \requestname{DBESwapBuffers} is included in an idiom, that +request's swap action will still be valid, and if the swap action +might overlap with another request, then the final result of the idiom +must be as if the separate requests were executed serially. For +example, if the specified swap action is \literal{Untouched}, and if a +\requestname{PolyFillRectangle} using a client clip rectangle is done +to the window's back buffer after the \requestname{DBESwapBuffers} +request, then the contents of the new back buffer (after the idiom) +will be the same as if the idiom was not recognized by the +implementation. + +It is highly recommended that Application Programming Interface (API) +providers define, and application developers use, ``convenience'' functions +that allow client applications to call one procedure that encapsulates common idioms. +These functions will generate the \requestname{DBEBeginIdiom} request, +the idiom requests, and \requestname{DBEEndIdiom} request. Usage of +these functions will ensure best possible performance across a wide +variety of implementations. + +\section{C Language Binding} + +The header for this extension is \verb|<X11/extensions/Xdbe.h>|. All +identifier names provided by this header begin with Xdbe. + +\subsection{Types} + +The type \libtypename{XdbeBackBuffer} is a \libtypename{Drawable}. + +The type \libtypename{XdbeSwapAction} can be one of the constants +\literal{XdbeUndefined}, \literal{XdbeBackground}, +\literal{XdbeUntouched}, or \literal{XdbeCopied}. + +\subsection{C Functions} + +The C functions provide direct access to the protocol and add no +additional semantics. For complete details on the effects of these +functions, refer to the appropriate protocol request, which can be +derived by replacing Xdbe at the start of the function name with DBE\@. +All functions that have return type \libtypename{Status} will return +nonzero for success and zero for failure. + +% start marker +\begin{keeptogether} +\begin{cfunction}{Status}{XdbeQueryExtension} +\cargdecl{Display *}{dpy}, +\cargdecl{int *}{major\_version\_return}, +\cargdecl{int *}{minor\_version\_return} +\end{cfunction} +% end marker + +\cfunctionname{XdbeQueryExtension} sets major\_version\_return and +minor\_version\_return to the major and minor DBE protocol +version supported by the server. If the DBE library is compatible +with the version returned by the server, it returns +nonzero. If dpy does not support the DBE 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 Xdbe functions may be called before this +function. If a client violates this rule, the effects of all +subsequent Xdbe calls that it makes are undefined. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{XdbeScreenVisualInfo *}{XdbeGetVisualInfo} +\cargdecl{Display *}{dpy}, +\cargdecl{Drawable *}{screen\_specifiers}, +\cargdecl{int *}{num\_screens} +\end{cfunction} +% end marker + +\cfunctionname{XdbeGetVisualInfo} returns information about which visuals support +double buffering. The argument num\_screens specifies how many +elements there are in the screen\_specifiers list. Each +drawable in screen\_specifiers designates a screen for which +the supported visuals are being requested. If num\_screens +is zero, information for all screens is requested. In this case, upon +return from this function, num\_screens will be set to the +number of screens that were found. If an error occurs, this function +returns NULL; otherwise, it returns a pointer to a list of +\libtypename{XdbeScreenVisualInfo} structures of length num\_screens. +The {\it n}th element in the returned list corresponds to the {\it n}th +drawable in the screen\_specifiers list, unless +num\_screens was passed in with the value zero, in which +case the {\it n}th element in the returned list corresponds to the +{\it n}th screen of the server, starting with screen zero. + +The \libtypename{XdbeScreenVisualInfo} structure has the following +fields: + +\begin{tabular}{lll} +\typename{int} & \argname{count} & number of items in visinfo \\ +\typename{XdbeVisualInfo *} & \argname{visinfo} & list of visuals and depths for this screen \\ +\end{tabular} + +The \libtypename{XdbeVisualInfo} structure has the following fields: + +\begin{tabular}{lll} +\typename{VisualID} & \argname{visual} & one visual ID that supports double-buffering\\ +\typename{int} & \argname{depth} & depth of visual in bits \\ +\typename{int} & \argname{perflevel} & performance level of visual \\ +\end{tabular} +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{void }{XdbeFreeVisualInfo} +\cargdecl{XdbeScreenVisualInfo *}{visual\_info} +\end{cfunction} +% end marker + +\cfunctionname{XdbeFreeVisualInfo} frees the list of \libtypename{XdbeScreenVisualInfo} +returned by \cfunctionname{XdbeGetVisualInfo}. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{XdbeBackBuffer}{XdbeAllocateBackBufferName} +\cargdecl{Display *}{dpy}, +\cargdecl{Window}{window}, +\cargdecl{XdbeSwapAction}{swap\_action} +\end{cfunction} +% end marker + +\cfunctionname{XdbeAllocateBackBufferName} returns a drawable ID used to refer +to the back buffer of the specified window. +The swap\_action is a hint to indicate the swap action +that will likely be used in subsequent calls to +\cfunctionname{XdbeSwapBuffers}. +The actual swap action used in calls to +\cfunctionname{XdbeSwapBuffers} does not have +to be the same as the swap\_action passed to this function, +though clients are encouraged to provide accurate information whenever +possible. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{Status}{XdbeDeallocateBackBufferName} +\cargdecl{Display *}{dpy}, +\cargdecl{XdbeBackBuffer}{buffer} +\end{cfunction} +% end marker + +\cfunctionname{XdbeDeallocateBackBufferName} frees the specified +drawable ID, buffer, +that was obtained via \cfunctionname{XdbeAllocateBackBufferName}. The buffer +must be a valid name for the back buffer of a window, or an +\literal{XdbeBadBuffer} +error results. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{Status}{XdbeSwapBuffers} +\cargdecl{Display *}{dpy}, +\cargdecl{XdbeSwapInfo *}{swap\_info}, +\cargdecl{int}{num\_windows} +\end{cfunction} +% end marker + +\cfunctionname{XdbeSwapBuffers} swaps the front and back buffers for a list of windows. +The argument num\_windows specifies how many windows are to +have their buffers swapped; it is the number of elements in the +swap\_info array. The argument swap\_info +specifies the information needed per window to do the swap. + +The \libtypename{XdbeSwapInfo} structure has the following fields: + +\begin{tabular}{lll} +\typename{Window} & \argname{swap\_window} & window for which to swap buffers \\ +\typename{XdbeSwapAction} & \argname{swap\_action} & swap action to use for this swap\_window \\ +\end{tabular} +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{Status}{XdbeBeginIdiom} +\cargdecl{Display *}{dpy} +\end{cfunction} +% end marker + +\cfunctionname{XdbeBeginIdiom} marks the beginning of an idiom sequence. +See section 3.2 +for a complete discussion of idioms. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{Status}{XdbeEndIdiom} +\cargdecl{Display *}{dpy} +\end{cfunction} +% end marker + +\cfunctionname{XdbeEndIdiom} marks the end of an idiom sequence. +\end{keeptogether} + +% start marker +\begin{keeptogether} +\begin{cfunction}{XdbeBackBufferAttributes *}{XdbeGetBackBufferAttributes} +\cargdecl{Display *}{dpy}, +\cargdecl{XdbeBackBuffer}{buffer} +\end{cfunction} +% end marker + +\cfunctionname{XdbeGetBackBufferAttributes} returns the attributes associated +with the specified buffer. + +The \libtypename{XdbeBackBufferAttributes} structure has the following fields: + +\begin{tabular}{lll} +\typename{Window} & \argname{window} & window that buffer belongs to \\ +\end{tabular} + +If buffer is not a valid \libtypename{XdbeBackBuffer}, +window is set to \literal{None}. + +The returned \libtypename{XdbeBackBufferAttributes} structure can be +freed with the Xlib function \cfunctionname{XFree}. +\end{keeptogether} + +\begin{keeptogether} +\subsection{Errors} + +The \libtypename{XdbeBufferError} structure has the following fields: + +\begin{tabular}{lll} +\typename{int} & \argname{type} \\ +\typename{Display *} & \argname{display}& Display the event was read from\\ +\typename{XdbeBackBuffer} & \argname{buffer}& resource id \\ +\typename{unsigned long} & \argname{serial}& serial number of failed request\\ +\typename{unsigned char} & \argname{error\_code}& error base + \literal{XdbeBadBuffer}\\ +\typename{unsigned char} & \argname{request\_code}& Major op-code of failed request\\ +\typename{unsigned char} & \argname{minor\_code}& Minor op-code of failed request\\ +\end{tabular} +\end{keeptogether} + +\pagebreak[4] +\section{Acknowledgements} + +We wish to thank the following individuals who have contributed their +time and talent toward shaping the DBE specification: + +T. Alex Chen, IBM; +Peter Daifuku, Silicon Graphics, Inc.; +Ian Elliott, Hewlett-Packard Company; +Stephen Gildea, X Consortium, Inc.; +Jim Graham, Sun; +Larry Hare, AGE Logic; +Jay Hersh, X Consortium, Inc.; +Daryl Huff, Sun; +Deron Dann Johnson, Sun; +Louis Khouw, Sun; +Mark Kilgard, Silicon Graphics, Inc.; +Rob Lembree, Digital Equipment Corporation; +Alan Ricker, Metheus; +Michael Rosenblum, Digital Equipment Corporation; +Bob Scheifler, X Consortium, Inc.; +Larry Seiler, Digital Equipment Corporation; +Jeanne Sparlin Smith, IBM; +Jeff Stevenson, Hewlett-Packard Company; +Walter Strand, Metheus; +Ken Tidwell, Hewlett-Packard Company; and +David P. Wiggins, X Consortium, Inc. + +Mark provided the impetus to start the DBE project. Ian wrote the +first draft of the specification. David served as architect. + +\section{References} + +Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, ``Multi-buffering Extension +Specification Version 3.3.'' + +Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins, +``X Synchronization Extension Version 3.0.'' + +\end{document} diff --git a/specs/shapelib.ms b/specs/shapelib.ms new file mode 100644 index 0000000..e8fcdc8 --- /dev/null +++ b/specs/shapelib.ms @@ -0,0 +1,556 @@ +.\" Use -ms and macros.t +.\" $Xorg: shapelib.ms,v 1.3 2000/08/17 19:42:36 cpqbld Exp $ +.\" $XdotOrg: xc/doc/specs/Xext/shapelib.ms,v 1.2 2004/04/23 18:42:18 eich Exp $ +.\" edited for DP edits and code consistency w/ core protocol/xlib 4/1/96 +.EH '''' +.OH '''' +.EF '''' +.OF '''' +.ps 10 +.nr PS 10 +\& +.sp 8 +.ce 3 +\s+2\fBX Nonrectangular Window + +Shape Extension Library\fP\s-2 +.sp 3 +.ce 3 +Version 1.0 +X Consortium Standard +X Version 11, Release 6.8 +.sp 6 +.ce 4 +\s-1Keith Packard +.sp 6p +MIT X Consortium +.ps 9 +.nr PS 9 +.sp 8 +.LP +Copyright \(co 1989 X Consortium +.LP +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: +.LP +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. +.LP +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. +.LP +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. +.ps 10 +.nr PS 10 +.bp 1 +.EH ''X Nonrectangular Window Shape Extension Library'' +.OH ''X Nonrectangular Window Shape Extension Library'' +.EF ''\fB % \fP'' +.OF ''\fB % \fP'' +.NH 1 +Overview +.LP +This extension provides arbitrary window and border shapes within the X11 +protocol. +.LP +The restriction of rectangular windows within the X protocol is a significant +limitation in the implementation of many styles of user interface. For +example, many transient windows would like to display a ``drop shadow'' to +give the illusion of 3 dimensions. As another example, some user interface +style guides call for buttons with rounded corners; the full simulation of a +nonrectangular shape, particularly with respect to event distribution and +cursor shape, is not possible within the core X protocol. As a final +example, round clocks and nonrectangular icons are desirable visual addition +to the desktop. +.LP +This extension provides mechanisms for changing the visible shape of a +window to an arbitrary, possibly disjoint, nonrectangular form. The intent +of the extension is to supplement the existing semantics, not replace them. +In particular, it is desirable for clients that are unaware of the +extension to still be able to cope reasonably with shaped windows. For +example, window managers should still be able to negotiate screen +real estate in rectangular pieces. Toward this end, any shape specified for +a window is clipped by the bounding rectangle for the window as specified by +the window's geometry in the core protocol. An expected convention would be +that client programs expand their shape to fill the area offered by the +window manager. +.NH 1 +Description +.LP +Each window (even with no shapes specified) is defined by two regions: the +\fIbounding region\fP and the \fIclip region\fP. The bounding region is the area of the +parent window that the window will occupy (including border). The clip region +is the subset of the bounding region that is available for subwindows and +graphics. The area between the bounding region and the clip region is defined +to be the border of the window. +.LP +A nonshaped window will have a bounding region that is a rectangle +spanning the window, including its border; the clip region will be a rectangle +filling the inside dimensions (not including the border). In this document, +these areas are referred to as the \fIdefault bounding region\fP and the +\fIdefault clip region\fP. For a window with inside size of \fIwidth\fP by +\fIheight\fP and border width \fIbwidth\fP, the default bounding and clip +regions are the rectangles (relative to the window origin): +.LP +.sM +.Ds 0 +bounding.x = -\fIbwidth\fP +bounding.y = -\fIbwidth\fP +bounding.width = \fIwidth\fP + 2 * \fIbwidth\fP +bounding.height = \fIheight\fP + 2 * \fIbwidth\fP + +clip.x = 0 +clip.y = 0 +clip.width = \fIwidth\fP +clip.height = \fIheight\fP +.De +.LP +.eM +This extension allows a client to modify either or both of the bounding or +clip regions by specifying new regions that combine with the default +regions. These new regions are called the \fIclient bounding region\fP and +the \fIclient clip region\fP. They are specified relative to the origin of +the window and are always defined by offsets relative to the window origin +(that is, region adjustments are not required when the window is moved). +Three mechanisms for specifying regions are provided: a list of rectangles, +a bitmap, and an existing bounding or clip region from a window. This is +modeled on the specification of regions in graphics contexts in the core +protocol and allows a variety of different uses of the extension. +.LP +When using an existing window shape as an operand in specifying a new shape, +the client region is used, unless none has been set, in which case the +default region is used instead. +.LP +The \fIeffective bounding region\fP of a window is defined to be the intersection of +the client bounding region with the default bounding region. Any portion of +the client bounding region that is not included in the default bounding +region will not be included in the effective bounding region on the screen. +This means that window managers (or other geometry managers) used to dealing +with rectangular client windows will be able to constrain the client to a +rectangular area of the screen. +.LP +Construction of the effective bounding region is dynamic; the client bounding +region is not mutated to obtain the effective bounding region. If a client +bounding region is specified that extends beyond the current default bounding +region, and the window is later enlarged, the effective bounding region will +be enlarged to include more of the client bounding region. +.LP +The \fIeffective clip region\fP of a window is defined to be the intersection of the +client clip region with both the default clip region and the client bounding +region. Any portion of the client clip region that is not included in both +the default clip region and the client bounding region will not be included in +the effective clip region on the screen. +.LP +Construction of the effective clip region is dynamic; the client clip region is +not mutated to obtain the effective clip region. If a client clip region is +specified that extends beyond the current default clip region and the +window or its bounding region is later enlarged, the effective clip region will +be enlarged to include more of the client clip region if it is included in +the effective bounding region. +.LP +The border of a window is defined to be the difference between the effective +bounding region and the effective clip region. If this region is empty, no +border is displayed. If this region is nonempty, the border is filled +using the border-tile or border-pixel of the window as specified in the core +protocol. Note that a window with a nonzero border width will never be able +to draw beyond the default clip region of the window. Also note that a zero +border width does not prevent a window from having a border, since the clip +shape can still be made smaller than the bounding shape. +.LP +All output to the window and visible regions of any subwindows will be +clipped to the effective clip region. The server must not retain window +contents beyond the effective bounding region with backing store. The window's +origin (for graphics operations, background tiling, and subwindow placement) +is not affected by the existence of a bounding region or clip region. +.LP +Areas that are inside the default bounding region but outside the effective +bounding region are not part of the window; these areas of the screen will +be occupied by other windows. Input events that occur within the default +bounding region but outside the effective bounding region will be delivered as +if the window was not occluding the event position. Events that occur in +a nonrectangular border of a window will be delivered to that window, just +as for events that occur in a normal rectangular border. +.LP +An +.PN InputOnly +window can have its bounding region set, but it is a +.PN Match +error to attempt to set a clip region on an +.PN InputOnly +window or to specify its clip region as a source to a request +in this extension. +.LP +The server must accept changes to the clip region of a root window, but +the server is permitted to ignore requested changes to the bounding region +of a root window. If the server accepts bounding region changes, the contents +of the screen outside the bounding region are implementation dependent. +.NH 1 +C Language Binding +.LP +The C functions provide direct access to the protocol and add no additional +semantics. +.LP +The include file for this extension is +.Pn < X11/extensions/shape.h >. +The defined shape kinds are +.PN ShapeBounding +and +.PN ShapeClip . +The defined region operations are +.PN ShapeSet , +.PN ShapeUnion , +.PN ShapeIntersect , +.PN ShapeSubtract , +and +.PN ShapeInvert . +.sM +.FD 0 +Bool +XShapeQueryExtension(\fIdisplay\fP\^, \fIevent_base\fP\^, \fIerror_base\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + int *\fIevent_base\fP\^; /* RETURN */ +.br + int *\fIerror_base\fP\^; /* RETURN */ +.FN +.LP +.eM +.PN XShapeQueryExtension +returns +.PN True +if the specified display supports the SHAPE extension else +.PN False . +If the extension is supported, *event_base is set to the event number for +.PN ShapeNotify +events and *error_base would be set to the error number for the first error for +this extension. +Because no errors are defined for this version of the extension, +the value returned here is not defined (nor useful). +.LP +.sp +.sM +.FD 0 +Status +XShapeQueryVersion(\fIdisplay\fP\^, \fImajor_version\fP\^, \fIminor_version\fP\^) +.br + Display *\fIdisplay\fP; +.br + int *\fImajor_version\fP, *\fIminor_version\fP\^; /* RETURN */ +.FN +.LP +.eM +If the extension is supported, +.PN XShapeQueryVersion +sets the major and minor version numbers of the +extension supported by the display and returns a nonzero value. +Otherwise, the arguments are not set and zero is returned. +.LP +.sp +.sM +.FD 0 +XShapeCombineRegion(\fIdisplay\fP\^, \fIdest\fP\^, \fIdest_kind\fP\^, \ +\fIx_off\fP\^, \fIy_off\fP\^, \fIregion\fP\^, \fIop\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIdest\fP\^; +.br + int \fIdest_kind\fP\^, \fIop\fP\^, \fIx_off\fP\^, \fIy_off\fP\^; +.br + REGION *\fIregion\fP\^; +.FN +.LP +.eM +.PN XShapeCombineRegion +converts the specified region into a list of rectangles and calls +.PN XShapeCombineRectangles . +.LP +.sp +.sM +.FD 0 +XShapeCombineRectangles(\fIdisplay\fP\^, \fIdest\fP\^, \fIdest_kind\fP\^, \ +\fIx_off\fP\^, \fIy_off\fP\^, \fIrectangles\fP\^, \fIn_rects\fP\^, \fIop\fP\^, \ +\fIordering\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIdest\fP\^; +.br + int \fIdest_kind\fP\^, \fIn_rects\fP\^, \fIop\fP\^, \fIx_off\fP\^, \ +\fIy_off\fP\^, \fIordering\fP\^; +.br + XRectangle *\fIrectangles\fP\^; +.FN +.LP +.eM +If the extension is supported, +.PN XShapeCombineRectangles +performs a +.PN ShapeRectangles +operation; otherwise, the request is ignored. +.LP +.sp +.sM +.FD 0 +XShapeCombineMask(\fIdisplay\fP\^, \fIdest\fP\^, \fIdest_kind\fP\^, \ +\fIx_off\fP\^, \fIy_off\fP\^, \fIsrc\fP\^, \fIop\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIdest\fP\^; +.br + int \fIdest_kind\fP\^, \fIop\fP\^, \fIx_off\fP\^, \fIy_off\fP\^; +.br + Pixmap \fIsrc\fP\^; +.FN +.LP +.eM +If the extension is supported, +.PN XShapeCombineMask +performs a +.PN ShapeMask +operation; otherwise, the request is ignored. +.LP +.sp +.sM +.FD 0 +XShapeCombineShape(\fIdisplay\fP\^, \fIdest\fP\^, \fIdest_kind\fP\^, \ +\fIx_off\fP\^, \fIy_off\fP\^, \fIsrc\fP\^, \fIsrc_kind\fP\^, \fIop\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIdest\fP\^, \fIsrc\fP\^; +.br + int \fIdest_kind\fP\^, \fIsrc_kind\fP\^, \fIop\fP\^, \fIx_off\fP\^, \fIy_off\fP\^; +.FN +.LP +.eM +If the extension is supported, +.PN XShapeCombineShape +performs a +.PN ShapeCombine +operation; otherwise, the request is ignored. +.LP +.sp +.sM +.FD 0 +XShapeOffsetShape(\fIdisplay\fP\^, \fIdest\fP\^, \fIdest_kind\fP\^, \ +\fIx_off\fP\^, \fIy_off\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIdest\fP\^; +.br + int \fIdest_kind\fP\^, fIx_off\fP\^, \fIy_off\fP\^; +.FN +.LP +.eM +If the extension is supported, +.PN XShapeOffsetShape +performs a +.PN ShapeOffset +operation; otherwise, the request is ignored. +.LP +.sp +.sM +.FD 0 +Status XShapeQueryExtents(\fIdisplay\fP\^, \fIwindow\fP\^, \ +\fIbounding_shaped\fP\^, \fIx_bounding\fP\^, \fIy_bounding\fP\^, +.br + \fIw_bounding\fP\^, \ \fIh_bounding\fP\^, \fIclip_shaped\fP\^, \ +\fIx_clip\fP\^, \fIy_clip\fP\^, \fIw_clip\fP\^, \fIh_clip\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIwindow\fP\^; +.br + Bool *\fIbounding_shaped\fP\^, *\fIclip_shaped\fP\^; /* RETURN */ +.br + int *\fIx_bounding\fP\^, *\fIy_bounding\fP\^, *\fIx_clip\fP\^, \ +*\fIy_clip\fP\^; /* RETURN */ +.br + unsigned int *\fIw_bounding\fP\^, *\fIh_bounding\fP\^, *\fIw_clip\fP\^, \ +* \fIh_clip\fP\^; /* RETURN */ +.FN +.LP +.eM +If the extension is supported, +.PN XShapeQueryExtents +sets x_bounding, y_bounding, w_bounding, h_bounding to the extents of the +bounding shape and sets x_clip, y_clip, w_clip, h_clip to the extents of +the clip shape. For unspecified client regions, the extents of the +corresponding default region are used. +.LP +If the extension is supported, +a nonzero value is returned; otherwise, zero is returned. +.LP +.sp +.sM +.FD 0 +XShapeSelectInput(\fIdisplay\fP\^, \fIwindow\fP\^, \fImask\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIwindow\fP\^; +.br + unsigned long \fImask\fP\^; +.FN +.LP +.eM +To make this extension more compatible with other interfaces, although +only one event type can be selected via the extension, +.PN XShapeSelectInput +provides a general mechanism similar to the standard Xlib binding for +window events. A mask value has been defined, +.PN ShapeNotifyMask +that is the only valid bit in mask that may be specified. +The structure for this event is defined as follows: +.LP +.sM +.Ds 0 +.TA 1.5i +.ta 1.5i +typedef struct { + int type; /* of event */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came frome a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* window of event */ + int kind; /* ShapeBounding or ShapeClip */ + int x, y; /* extents of new region */ + unsigned width, height; + Time time; /* server timestamp when region changed */ + Bool shaped; /* true if the region exists */ +} XShapeEvent; +.De +.LP +.eM +.LP +.sM +.FD 0 +unsigned long +XShapeInputSelected(\fIdisplay\fP\^, \fIwindow\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIwindow\fP\^; +.FN +.LP +.eM +.PN XShapeInputSelected +returns the current input mask for extension events on the specified +window; the value returned if +.PN ShapeNotify +is selected for is +.PN ShapeNotifyMask ; +otherwise, it returns zero. +If the extension is not supported, it returns zero. +.LP +.sp +.sM +.FD 0 +XRectangle * +XShapeGetRectangles(\fIdisplay\fP\^, \fIwindow\fP\^, \fIkind\fP\^, \ +\fIcount\fP\^, \fIordering\fP\^) +.br + Display *\fIdisplay\fP\^; +.br + Window \fIwindow\fP\^; +.br + int \fIkind\fP\^; +.br + int *\fIcount\fP\^; /* RETURN */ +.br + int *\fIordering\fP\^; /* RETURN */ +.FN +.LP +.eM +If the extension is not supported, +.PN XShapeGetRectangles +returns NULL. +Otherwise, it returns a list of rectangles that describe the region +specified by kind. +.NH 1 +Glossary +.LP +.KS +\fBbounding region\fP +.IP +The area of the parent window that this window will occupy. This area is +divided into two parts: the border and the interior. +.KE +.LP +.KS +\fBclip region\fP +.IP +The interior of the window, as a subset of the bounding region. This +region describes the area that will be painted with the window background +when the window is cleared, will contain all graphics output to the window, +and will clip any subwindows. +.KE +.LP +.KS +\fBdefault bounding region\fP +.IP +The rectangular area, as described by the core protocol window size, that +covers the interior of the window and its border. +.KE +.LP +.KS +\fBdefault clip region\fP +.IP +The rectangular area, as described by the core protocol window size, that +covers the interior of the window and excludes the border. +.KE +.LP +.KS +\fBclient bounding region\fP +.IP +The region associated with a window that is directly modified via this +extension when specified by +.PN ShapeBounding . +This region is used in conjunction with the default bounding region +to produce the effective bounding region. +.KE +.LP +.KS +\fBclient clip region\fP +.IP +The region associated with a window that is directly modified via this +extension when specified by +.PN ShapeClip . +This region is used in conjunction with the default clip region +and the client bounding region to produce the effective clip region. +.KE +.LP +.KS +\fBeffective bounding region\fP +.IP +The actual shape of the window on the screen, including border and interior +(but excluding the effects of overlapping windows). When a window has a client +bounding region, the effective bounding region is the intersection of the +default bounding region and the client bounding region. Otherwise, the +effective bounding region is the same as the default bounding region. +.KE +.LP +.KS +\fBeffective clip region\fP +.IP +The actual shape of the interior of the window on the screen (excluding the +effects of overlapping windows). When a window has a client clip region or +a client bounding region, the effective clip region is the intersection of +the default clip region, the client clip region (if any) and the client +bounding region (if any). Otherwise, the effective clip region is the +same as the default clip region. +.KE diff --git a/specs/synclib.tex b/specs/synclib.tex new file mode 100644 index 0000000..33249a1 --- /dev/null +++ b/specs/synclib.tex @@ -0,0 +1,773 @@ +% $Xorg: synclib.tex,v 1.3 2000/08/17 19:42:37 cpqbld Exp $ +% $XdotOrg: xc/doc/specs/Xext/synclib.tex,v 1.2 2004/04/23 18:42:18 eich Exp $ +% +% Copyright 1991 by Olivetti Research Limited, Cambridge, England and +% Digital Equipment Corporation, Maynard, Massachusetts. +% +% All Rights Reserved +% +% Permission to use, copy, modify, and distribute this software and its +% documentation for any purpose and without fee is hereby granted, +% provided that the above copyright notice appear in all copies and that +% both that copyright notice and this permission notice appear in +% supporting documentation, and that the names of Digital or Olivetti +% not be used in advertising or publicity pertaining to distribution of the +% software without specific, written prior permission. +% +% DIGITAL AND OLIVETTI DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, +% INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT +% SHALL THEY BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +% ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER +% IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +% OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +%\documentstyle[a4]{article} +\documentstyle{article} + +\setlength{\parindent}{0 pt} +\setlength{\parskip}{6pt} + +% Protocol Section +% For the DP book, these four should be assigned the font for global symbols. + +\newcommand{\request}[1]{{\bf #1}} +\newcommand{\event}[1]{{\bf #1}} +\newcommand{\error}[1]{{\bf #1}} +\newcommand{\enum}[1]{{\bf #1}} + +% The following fonts are not reassigned for the DP book. + +\newcommand{\system}[1]{{\sc #1}} +\newcommand{\param}[1]{{\it #1}} + +\newcommand{\eventdef}[1]{\item {\bf#1}} +\newcommand{\requestdef}[1]{\item {\bf#1}} +\newcommand{\errordef}[1]{\item {\bf#1}} + +\newcommand{\defn}[1]{{\bf #1}} + +\newcommand{\tabstopsA}{\hspace*{4cm}\=\hspace*{1cm}\=\hspace*{7cm}\=\kill} +\newcommand{\tabstopsB}{\hspace*{1cm}\=\hspace*{1cm}\=\hspace*{3cm}\=\kill} +\newcommand{\tabstopsC}{\hspace*{1cm}\=\hspace*{1cm}\=\hspace*{5cm}\=\kill} + +% commands for formatting the API +% For the DP book, these three should be assigned the font for global symbols. + +\newcommand{\cfunctionname}[1]{\mbox{\tt#1}} +\newcommand{\ctypename}[1]{\mbox{\tt#1}} +\newcommand{\cconst}[1]{\mbox{\tt#1}} + +% For the DP book, within function definitions, the type and name are in +% the ordinary font; therefore, ctypenamedef and cfunctionnamedef are used +% and defined below. +\newcommand{\ctypenamedef}[1]{\mbox{#1}} +\newcommand{\cfunctionnamedef}[1]{\mbox{#1}} +\newcommand{\cargname}[1]{\mbox{\it#1}} +\newcommand{\cstartfunction}[2]{\begin{sloppypar}\begin{samepage}\ctypenamedef{#1}\\ \cfunctionnamedef{#2}\ (} +\newcommand{\cargdecl}[2]{\penalty -1\ctypenamedef{#1} \cargname{#2}} +\newcommand{\cendfunctiondecl}{){\hangafter=2 \hangindent=20pt \raggedright\par}} +\newcommand{\cendfuncdescription}{\end{samepage}\end{sloppypar}} + +\newcommand{\cstartmacro}[2]{\begin{sloppypar}\begin{samepage}\ctypenamedef{#1}\\ \cfunctionnamedef{#2}\ (} +\newcommand{\cendmacrodecl}{)\par} +\newcommand{\cendmacrodescription}{\end{samepage}\end{sloppypar}} + +% make things easier with all the long names +\spaceskip .3333em plus 5em +\tolerance=2000 + +\begin{document} + +\begin{center} + +{\large X Synchronization Extension Library}\\[10pt] +{\large Version 3.0}\\[15pt] +{\large X Consortium Standard}\\[15pt] +{\large X Version 11, Release 6.8}\\[15pt] +{\it Tim Glauert}\\[0pt] +{\tt thg@cam-orl.co.uk}\\[0pt] +{\bf Olivetti Research / MultiWorks}\\[5pt] +{\it Dave Carver}\\[0pt] +{\tt dcc@athena.mit.edu}\\[0pt] +{\bf Digital Equipment Corporation,}\\[0pt] +{\bf MIT / Project Athena}\\[5pt] +{\it Jim Gettys}\\[0pt] +{\tt jg@crl.dec.com}\\[0pt] +{\bf Digital Equipment Corporation,}\\[0pt] +{\bf Cambridge Research Laboratory}\\[5pt] +{\it David P. Wiggins}\\[0pt] +{\tt dpw@x.org}\\[0pt] +{\bf X Consortium, Inc.}\\[0pt] + +\end {center} + +Copyright 1991 by Olivetti Research Limited, Cambridge, England and +Digital Equipment Corporation, Maynard, Massachusetts. + +{\small Permission to use, copy, modify, and distribute this documentation +for any purpose and without fee is hereby granted, provided that the above +copyright notice appear in all copies. Olivetti, Digital, MIT, and the +X Consortium +make no representations about the suitability for any purpose of the +information in this document. This documentation is provided as is without +express or implied warranty.} + +Copyright (c) 1991 X Consortium, Inc. + +{\small 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.} +\eject + +\section{Synchronization Protocol} + +The core X protocol makes no guarantees about the relative order of execution +of requests for different clients. This means that any synchronization between +clients must be done at the client level in an operating system-dependent and +network-dependent manner. Even if there was an accepted standard for such +synchronization, the use of a network introduces unpredictable delays between +the synchronization of the clients and the delivery of the resulting requests +to the X server. + +The core X protocol also makes no guarantees about the time at which requests +are executed, which means that all clients with real-time constraints must +implement their timing on the host computer. Any such timings are subject to +error introduced by delays within the operating system and network and are +inefficient because of the need for round-trip requests that keep the client and +server synchronized. + +The synchronization extension provides primitives that allow synchronization +between clients to take place entirely within the X server. This removes any +error introduced by the network and makes it possible to synchronize clients +on different hosts running different operating systems. This is important for +multimedia applications, where audio, video, and graphics data streams are +being synchronized. The extension also provides internal timers within the X +server to which client requests can be synchronized. This allows simple +animation applications to be implemented without any round-trip requests and +makes best use of buffering within the client, network, and server. + +\subsection{Description} + +The mechanism used by this extension for synchronization within the X server +is to block the processing of requests from a client until a specific +synchronization condition occurs. When the condition occurs, the client is +released and processing of requests continues. Multiple clients may block on +the same condition to give inter-client synchronization. Alternatively, a +single client may block on a condition such as an animation frame marker. + +The extension adds \defn{Counter} and \defn{Alarm} to the set of resources +managed by the server. A counter has a 64-bit integer value that may be +increased or decreased by client requests or by the server internally. A +client can block by sending an \request{Await} request that waits until +one of a set of synchronization conditions, called TRIGGERs, becomes TRUE. + +The \request{CreateCounter} request allows a client to create a +\defn{Counter} that can be changed by explicit \request{SetCounter} and +\request{ChangeCounter} requests. These can be used to implement +synchronization between different clients. + +There are some counters, called \defn{System Counters}, that are changed by +the server internally rather than by client requests. The effect of any change +to a system counter is not visible until the server has finished processing the +current request. In other words, system counters are apparently updated in the +gaps between the execution of requests rather than during the actual execution +of a request. The extension provides a system counter that advances with the +server time as defined by the core protocol, and it may also provide counters +that advance with the real-world time or that change each time the CRT +screen is refreshed. Other extensions may provide their own +extension-specific system counters. + +The extension provides an \defn{Alarm} mechanism that allows clients to +receive an event on a regular basis when a particular counter is changed. + +\section{C Language Binding} + +The C routines provide direct access to the protocol and add +no additional semantics. + +The include file for this extension is \verb|<X11/extensions/sync.h>|. + +Most of the names in the language binding are derived from the +protocol names by prepending \cfunctionname{XSync} to the protocol name and changing +the capitalization. + +\subsection{C Functions} + +Most of the following functions generate SYNC protocol requests. + +% start marker +\cstartfunction{Status}{XSyncQueryExtension} +\cargdecl{Display *}{dpy}, +\cargdecl{int *}{event\_base\_return}, +\cargdecl{int *}{error\_base\_return} +\cendfunctiondecl +% end marker + +If dpy supports the SYNC extension, \cfunctionname{XSyncQueryExtension} +returns \cconst{True}, sets *event\_base\_return to the event number for the +first SYNC event, and sets +*error\_base\_return to the error number for the first SYNC +error. If dpy does not support the SYNC extension, it +returns \cconst{False}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncInitialize} +\cargdecl{Display *}{dpy}, +\cargdecl{int *}{major\_version\_return}, +\cargdecl{int *}{minor\_version\_return} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncInitialize} sets *major\_version\_return and +*minor\_version\_return to the major/minor SYNC protocol +version supported by the server. If the XSync library is compatible +with the version returned by the server, this function returns \cconst{True}. +If dpy does not support the SYNC extension, or if there was an error during +communication with the server, or if the server and library protocol +versions are incompatible, this function returns \cconst{False}. The only +XSync function that may be called before this function is +\cfunctionname{XSyncQueryExtension}. If a client violates this rule, +the effects of all XSync calls that it makes are undefined. +\cendfuncdescription + + +% start marker +\cstartfunction{XSyncSystemCounter *}{XSyncListSystemCounters} +\cargdecl{Display *}{dpy}, +\cargdecl{int *}{n\_counters\_return} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncListSystemCounters} returns a pointer to an +array of system counters supported by the display and sets +*n\_counters\_return to the number of +counters in the array. The array should be freed with +\cfunctionname{XSyncFreeSystemCounterList}. If dpy does not +support the SYNC extension, +or if there was an error during communication with the +server, or if the server does not support any system counters, this +function returns NULL. + +\ctypename{XSyncSystemCounter} has the following fields: + +\begin{tabular}{lll} +char * & name; & /* null-terminated name of system counter */\\ +XSyncCounter & counter; & /* counter id of this system counter */\\ +XSyncValue & resolution; & /* resolution of this system counter */\\ +\end{tabular} +\cendfuncdescription + + +% start marker +\cstartfunction{void}{XSyncFreeSystemCounterList} +\cargdecl{XSyncSystemCounter *}{list} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncFreeSystemCounterList} frees the memory associated +with the system counter list returned by \cfunctionname{XSyncListSystemCounters}. +\cendfuncdescription + + +% start marker +\cstartfunction{XSyncCounter}{XSyncCreateCounter} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncValue}{initial\_value} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncCreateCounter} creates a counter on the dpy +with the given initial\_value and returns the counter ID. +It returns \cconst{None} if dpy does not +support the SYNC extension. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncSetCounter} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncCounter}{counter}, +\cargdecl{XSyncValue}{value} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncSetCounter} sets counter to value. +It returns \cconst{False} if dpy does not support the SYNC extension; +otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncChangeCounter} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncCounter}{counter}, +\cargdecl{XSyncValue}{value} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncChangeCounter} adds value to counter. +It returns \cconst{False} if dpy does not support the SYNC extension; +otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncDestroyCounter} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncCounter}{counter} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncDestroyCounter} destroys counter. +It returns \cconst{False} if dpy does not +support the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncQueryCounter} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncCounter}{counter}, +\cargdecl{XSyncValue *}{value\_return} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncQueryCounter} sets *value\_return to the current value of +counter. It returns \cconst{False} if there was an error during +communication with the server or if dpy does not support +the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncAwait} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncWaitCondition *}{wait\_list}, +\cargdecl{int}{n\_conditions} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncAwait} awaits on the conditions in wait\_list. +The n\_conditions is the number of wait conditions in +wait\_list. It returns \cconst{False} if dpy does not +support the SYNC extension; otherwise, it returns \cconst{True}. +The await is processed asynchronously by the server; +this function always returns immediately +after issuing the request. + +\ctypename{XSyncWaitCondition} has the following fields: + +\begin{tabular}{lll} +XSyncCounter & trigger.counter; & /* counter to trigger on */ \\ +XSyncValueType & trigger.value\_type; & /* absolute/relative */ \\ +XSyncValue & trigger.wait\_value; & /* value to compare counter to */ \\ +XSyncTestType & trigger.test\_type; & /* pos/neg comparison/transtion */ \\ +XSyncValue & event\_threshold; & /* send event if past threshold */ \\ +\end{tabular} + +\ctypename{XSyncValueType} can be either \cconst{XSyncAbsolute} or \cconst{XSyncRelative}. + +\ctypename{XSyncTestType} can be one of \cconst{XSyncPositiveTransition}, +\cconst{XSyncNegativeTransition}, \cconst{XSyncPositiveComparison}, or +\cconst{XSyncNegativeComparison}. +\cendfuncdescription + + +% start marker +\cstartfunction{XSyncAlarm}{XSyncCreateAlarm} +\cargdecl{Display *}{dpy}, +\cargdecl{unsigned long}{values\_mask}, +\cargdecl{XSyncAlarmAttributes *}{values} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncCreateAlarm} creates an alarm and returns the alarm ID. +It returns \cconst{None} if the display does not support the SYNC extension. +The values\_mask and values specify the alarm attributes. + +\ctypename{XSyncAlarmAttributes} has the following fields. The attribute\_mask +column specifies the symbol that the caller should OR into +values\_mask to indicate that the value for the corresponding +attribute was actually supplied. Default values are used for all +attributes that do not have their attribute\_mask OR'ed into +values\_mask. +See the protocol +description for \request{CreateAlarm} for the defaults. + +\begin{tabular}{lll} +type & field name & attribute\_mask \\ +XSyncCounter & trigger.counter; & \cconst{XSyncCACounter} \\ +XSyncValueType & trigger.value\_type; & \cconst{XSyncCAValueType} \\ +XSyncValue & trigger.wait\_value; & \cconst{XSyncCAValue} \\ +XSyncTestType & trigger.test\_type; & \cconst{XSyncCATestType} \\ +XSyncValue & delta; & \cconst{XSyncCADelta} \\ +Bool & events; & \cconst{XSyncCAEvents} \\ +XSyncAlarmState & state; & client cannot set this \\ +\end{tabular} +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncDestroyAlarm} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncAlarm}{alarm} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncDestroyAlarm} destroys alarm. +It returns \cconst{False} if dpy does not +support the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncQueryAlarm} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncAlarm}{alarm}, +\cargdecl{XSyncAlarmAttributes *}{values\_return} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncQueryAlarm} sets *values\_return to the alarm's +attributes. It returns \cconst{False} if there was an error +during communication with the server or if dpy does not support +the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncChangeAlarm} +\cargdecl{Display *}{dpy}, +\cargdecl{XSyncAlarm}{alarm}, +\cargdecl{unsigned long}{values\_mask}, +\cargdecl{XSyncAlarmAttributes *}{values} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncChangeAlarm} changes alarm's attributes. +The attributes to change are specified as in \cfunctionname{XSyncCreateAlarm}. +It returns \cconst{False} if dpy does not support the SYNC extension; +otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncSetPriority} +\cargdecl{Display *}{dpy}, +\cargdecl{XID}{client\_resource\_id}, +\cargdecl{int}{priority} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncSetPriority} sets the priority of the client owning +client\_resource\_id to priority. +If client\_resource\_id is \cconst{None}, +it sets the caller's priority. It returns \cconst{False} if dpy +does not support the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + + +% start marker +\cstartfunction{Status}{XSyncGetPriority} +\cargdecl{Display *}{dpy}, +\cargdecl{XID}{client\_resource\_id}, +\cargdecl{int *}{return\_priority} +\cendfunctiondecl +% end marker + +\cfunctionname{XSyncGetPriority} sets *return\_priority to the priority +of the client owning client\_resource\_id. +If client\_resource\_id is +\cconst{None}, it sets *return\_priority to the caller's priority. +It returns \cconst{False} if there was an error +during communication with the server or if dpy does not +support the SYNC extension; otherwise, it returns \cconst{True}. +\cendfuncdescription + +\subsection{C Macros/Functions} + +The following procedures manipulate 64-bit values. They are defined +both as macros and as functions. By default, the macro form is used. +To use the function form, \#undef the macro name to uncover the +function. + + +% start marker +\cstartmacro{void}{XSyncIntToValue} +\cargdecl{XSyncValue}{*pv}, +\cargdecl{int}{i} +\cendmacrodecl +% end marker + +Converts i to an \ctypename{XSyncValue} and stores it in +*pv. Performs sign extension (*pv will have the +same sign as i.) +\cendmacrodescription + + +% start marker +\cstartmacro{void}{XSyncIntsToValue} +\cargdecl{XSyncValue}{*pv}, +\cargdecl{unsigned int}{low}, +\cargdecl{int}{high} +\cendmacrodecl +% end marker + +Stores low in the low 32 bits of *pv and +high in the high 32 bits of *pv. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueGreaterThan} +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b} +\cendmacrodecl +% end marker + +Returns \cconst{True} if a is greater than b, +else returns \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueLessThan} +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b} +\cendmacrodecl +% end marker + +Returns \cconst{True} if a is less than b, +else returns \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueGreaterOrEqual} +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b} +\cendmacrodecl +% end marker + +Returns \cconst{True} if a is greater than or equal to b, +else returns \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueLessOrEqual} +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b} +\cendmacrodecl +% end marker + +Returns \cconst{True} if a is less than or equal to b. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueEqual} +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b} +\cendmacrodecl +% end marker + +Returns \cconst{True} if a is equal to b, +else returns \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueIsNegative} +\cargdecl{XSyncValue}{v} +\cendmacrodecl +% end marker + +Returns \cconst{True} if v is negative, else returns +\cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueIsZero} +\cargdecl{XSyncValue}{v} +\cendmacrodecl +% end marker + +Returns \cconst{True} if v is zero, +else returns \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{Bool}{XSyncValueIsPositive} +\cargdecl{XSyncValue}{v} +\cendmacrodecl +% end marker + +Returns \cconst{True} if v is positive, else returns +\cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{unsigned int}{XSyncValueLow32} +\cargdecl{XSyncValue}{v} +\cendmacrodecl +% end marker + +Returns the low 32 bits of v. +\cendmacrodescription + + +% start marker +\cstartmacro{int}{XSyncValueHigh32} +\cargdecl{XSyncValue}{v} +\cendmacrodecl +% end marker + +Returns the high 32 bits of v. +\cendmacrodescription + + +% start marker +\cstartmacro{void}{XSyncValueAdd} +\cargdecl{XSyncValue *}{presult}, +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b}, +\cargdecl{Bool *}{poverflow} +\cendmacrodecl +% end marker + +Adds a to b and stores the result in *presult. +If the result could not fit in 64 bits, *poverflow is set to +\cconst{True}, else it is set to \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{void}{XSyncValueSubtract} +\cargdecl{XSyncValue *}{presult}, +\cargdecl{XSyncValue}{a}, +\cargdecl{XSyncValue}{b}, +\cargdecl{Bool *}{poverflow} +\cendmacrodecl +% end marker + +Subtracts b from a and stores the result in +*presult. +If the result could not fit in 64 bits, overflow is set to +\cconst{True}, else it is set to \cconst{False}. +\cendmacrodescription + + +% start marker +\cstartmacro{void}{XSyncMaxValue} +\cargdecl{XSyncValue *}{pv} +\cendmacrodecl +% end marker + +Sets *pv to the maximum value expressible in 64 bits. +\cendmacrodescription + + +% start marker +\cstartmacro{void}{XSyncMinValue} +\cargdecl{XSyncValue *}{pv} +\cendmacrodecl +% end marker + +Sets *pv to the minimum value expressible in 64 bits. +\cendmacrodescription + +\subsection{Events} + +Let \cargname{event\_base} be the value \cargname{event\_base\_return} +as defined in the function \cfunctionname{XSyncQueryExtension}. + +An \ctypename{XSyncCounterNotifyEvent}'s type field has the value +\cargname{event\_base} + \cconst{XSyncCounterNotify}. The fields of +this structure are: + +\begin{tabular}{lll} +int & type; & /* event base + \cconst{XSyncCounterNotify} */ \\ +unsigned long & serial; & /* number of last request processed by server */ \\ +Bool & send\_event;& /* true if this came from a SendEvent request */ \\ +Display * & display; & /* Display the event was read from */\\ +XSyncCounter & counter; & /* counter involved in await */\\ +XSyncValue & wait\_value; & /* value being waited for */\\ +XSyncValue & counter\_value; & /* counter value when this event was sent */\\ +Time & time; & /* milliseconds */\\ +int & count; & /* how many more events to come */\\ +Bool & destroyed; & /* True if counter was destroyed */\\ +\end{tabular} + +An \ctypename{XSyncAlarmNotifyEvent}'s type field has the value +\cargname{event\_base} + \cconst{XSyncAlarmNotify}. The fields of this +structure are: + +\begin{tabular}{lll} +int & type;& /* event base + \cconst{XSyncAlarmNotify} */\\ +unsigned long & serial;&/* number of last request processed by server */\\ +Bool & send\_event;& /* true if this came from a SendEvent request */\\ +Display * & display;& /* Display the event was read from */\\ +XSyncAlarm & alarm;& /* alarm that triggered */\\ +XSyncValue & counter\_value;&/* value that triggered the alarm */\\ +XSyncValue & alarm\_value;& /* test value of trigger in alarm */\\ +Time & time;& /* milliseconds */\\ +XSyncAlarmState & state;& /* new state of alarm */\\ +\end{tabular} + +\subsection{Errors} + +Let \cargname{error\_base} be the value \cargname{error\_base\_return} +as defined in the function \cfunctionname{XSyncQueryExtension}. + +An \ctypename{XSyncAlarmError}'s error\_code field has the value +\cargname{error\_base} + \cconst{XSyncBadAlarm}. The fields of +this structure are: + +\begin{tabular}{lll} +int & type; \\ +Display * & display;& /* Display the event was read from */\\ +XSyncAlarm & alarm;& /* resource id */\\ +unsigned long & serial;& /* serial number of failed request */\\ +unsigned char & error\_code;&/* error base + XSyncBadAlarm */\\ +unsigned char & request\_code;&/* Major op-code of failed request */\\ +unsigned char & minor\_code;&/* Minor op-code of failed request */\\ +\end{tabular} + +An \ctypename{XSyncCounterError}'s error\_code field has the value +\cargname{error\_base} + \cconst{XSyncBadCounter}. The fields of +this structure are: + +\begin{tabular}{lll} +int &type;\\ +Display * & display;& /* Display the event was read from */\\ +XSyncCounter & counter;& /* resource id */\\ +unsigned long & serial;& /* serial number of failed request */\\ +unsigned char & error\_code;&/* error base + XSyncBadCounter */\\ +unsigned char & request\_code;&/* Major op-code of failed request */\\ +unsigned char & minor\_code;& /* Minor op-code of failed request */\\ +\end{tabular} + +\end{document} |