Index: create.patch.sh
===================================================================
--- create.patch.sh (nonexistent)
+++ create.patch.sh (revision 5)
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+VERSION=1.3.5
+
+tar --files-from=file.list -xJvf ../libXext-$VERSION.tar.xz
+mv libXext-$VERSION libXext-$VERSION-orig
+
+cp -rf ./libXext-$VERSION-new ./libXext-$VERSION
+
+diff --unified -Nr libXext-$VERSION-orig libXext-$VERSION > libXext-$VERSION-docbook.patch
+
+mv libXext-$VERSION-docbook.patch ../patches
+
+rm -rf ./libXext-$VERSION
+rm -rf ./libXext-$VERSION-orig
Property changes on: create.patch.sh
___________________________________________________________________
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: file.list
===================================================================
--- file.list (nonexistent)
+++ file.list (revision 5)
@@ -0,0 +1,2 @@
+libXext-1.3.5/specs/dbelib.xml
+libXext-1.3.5/specs/shapelib.xml
Index: libXext-1.3.5-new/specs/dbelib.xml
===================================================================
--- libXext-1.3.5-new/specs/dbelib.xml (nonexistent)
+++ libXext-1.3.5-new/specs/dbelib.xml (revision 5)
@@ -0,0 +1,741 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
+[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="dbelib">
+
+<bookinfo>
+ <title>Double Buffer Extension Library</title>
+ <subtitle>X Consortium Standard</subtitle>
+ <releaseinfo>X Version 11, Release &fullrelvers;</releaseinfo>
+ <releaseinfo>Version 1.0</releaseinfo>
+ <authorgroup>
+ <author>
+ <firstname>Ian</firstname><surname>Elliot</surname>
+ <affiliation><orgname>Hewlett-Packard Company</orgname></affiliation>
+ </author>
+ <othercredit>
+ <firstname>David</firstname><othername>P.</othername><surname>Wiggins</surname>
+ <affiliation><orgname>X Consortium, Inc</orgname></affiliation>
+ </othercredit>
+ </authorgroup>
+ <copyright><year>1989</year>
+ <holder>X Consortium Inc</holder>
+ <holder>Digital Equipment Corporation</holder>
+ </copyright>
+ <copyright><year>1992</year>
+ <holder>X Consortium Inc</holder>
+ <holder>Intergraph Corporation</holder>
+ </copyright>
+ <copyright><year>1993</year>
+ <holder>X Consortium Inc</holder>
+ <holder>Silicon Graphics, Inc.</holder>
+ </copyright>
+ <copyright><year>1994</year><year>1995</year>
+ <holder>X Consortium Inc</holder>
+ <holder>Hewlett-Packard Company</holder>
+ </copyright>
+
+<legalnotice>
+<para>
+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.
+</para>
+
+</legalnotice>
+
+</bookinfo>
+
+<chapter id='Introduction'>
+<title>Introduction</title>
+<para>
+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.
+</para>
+
+</chapter>
+
+<chapter id='Goals'>
+<title>Goals</title>
+
+<para>
+This extension should enable clients to:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+Allocate and deallocate double-buffering for a window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Draw to and read from the front and back buffers associated with a window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Swap the front and back buffers associated with a window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+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).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Request that the front and back buffers associated with multiple
+double-buffered windows be swapped simultaneously.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+In addition, the extension should:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+Allow multiple clients to use double-buffering on the same window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Support a range of implementation methods that can capitalize on
+existing hardware features.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Add no new event types.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Be reasonably easy to integrate with a variety of direct graphics
+hardware access (DGHA) architectures.
+ </para>
+ </listitem>
+</itemizedlist>
+
+</chapter>
+
+<chapter id='Concepts'>
+<title>Concepts</title>
+<para>
+Normal windows are created using the core CreateWindow request, which
+allocates a set of window attributes and, for 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.
+</para>
+<para>
+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 (XIDs) 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 DRAWABLE of type BACKBUFFER.
+</para>
+<para>
+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.
+</para>
+<para>
+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.
+</para>
+<para>
+In general, both the front and back buffers are treated the same.
+particular, here are some important characteristics:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+Only one buffer per window can be visible at a time (the front buffer).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Both buffers associated with a window have the same visual type, depth,
+width, height, and shape as the window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Both buffers associated with a window are "visible" (or "obscured") in
+the same way. When an 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 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It is acceptable at any time to pass a BACKBUFFER in any request,
+notably any core or extension drawing request, that expects a
+DRAWABLE. This enables an application to draw directly into
+BACKBUFFERs in the same fashion as it would draw into any other
+DRAWABLE.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It is an error (Window) to pass a BACKBUFFER in a core request that
+expects a Window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+A BACKBUFFER will never be sent by core X in a reply, event, or
+error where a Window is specified.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+If core X11 backing-store and save-under applies to a double-buffered
+window, it applies to both buffers equally.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+If the core ClearArea request is executed on a double-buffered window,
+the same area in both the front and back buffers is cleared.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+The effect of passing a window to a request that accepts a
+<function>DRAWABLE</function> is
+unchanged by this extension. The window and front buffer are synonymous
+with each other. This includes obeying the <function>GetImage</function>
+semantics and the
+subwindow-mode semantics if a core graphics context is involved. Regardless
+of whether the window was explicitly passed in a
+<function>GetImage</function> 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-naive screen dump clients will always get the front buffer.
+<function>GetImage</function> on
+a back buffer returns undefined image contents for any obscured regions of the
+back buffer that fall within the image.
+</para>
+<para>
+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
+<function>ClipByChildren</function>. If
+an ancestor of a double-buffered window is drawn to with a core GC having a
+subwindow-mode of 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 <function>IncludeInferiors</function> drawing touched.
+</para>
+
+
+<para>
+DBE adds no new events. DBE does not extend the semantics of any existing
+events with the exception of adding a new DRAWABLE type called
+BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for
+example, <function>GraphicsExpose</function>) are generated in response to
+a request, the
+DRAWABLE returned will be the one specified in the request.
+</para>
+<para>
+DBE advertises which visuals support double-buffering.
+</para>
+<para>
+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.
+</para>
+
+<sect1 id='Window_Management_Operations'>
+<title>Window Management Operations</title>
+
+<para>
+The basic philosophy of DBE is that both buffers are treated the same by core
+X window management operations.
+</para>
+<para>
+When the core <function>DestroyWindow</function> 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.
+</para>
+<para>
+If the core <function>ConfigureWindow</function> 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
+<function>ConfigureWindow</function>
+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,
+<function>Expose</function> events are
+generated for the region that is tiled with the window background.
+If the core GetGeometry request is executed on a BACKBUFFER, the
+returned x, y, and border-width will be zero.
+</para>
+<para>
+If the Shape extension
+<function>ShapeRectangles</function>,
+<function>ShapeMask</function>,
+<function>ShapeCombine</function>, or
+<function>ShapeOffset</function>
+request is executed on a double-buffered window, both buffers
+are reshaped to match the new window shape. The region difference is the
+following:
+</para>
+
+<literallayout remap='Ds'>
+ D = newshape − oldshape
+</literallayout>
+
+<para>
+It is tiled with the window background in both buffers, and
+<function>Expose</function>
+events are generated for D.
+</para>
+
+</sect1>
+
+<sect1 id='Complex_Swap_Actions'>
+<title>Complex Swap Actions</title>
+<para>
+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.
+</para>
+<para>
+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:
+<function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>.
+Unless this begin-end pair surrounds the idiom, it may not be recognized
+by a given implementation, and performance will suffer.
+</para>
+<para>
+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:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+<function>DBEBeginIdiom</function> request.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<function>DBESwapBuffers</function> request with XIDs for two windows, each of which uses
+a swap action of Untouched.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of one window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of the other
+window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<function>DBEEndIdiom</function> request.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+The <function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>
+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.
+</para>
+
+<para>
+
+An idiom need not include a <function>DBESwapBuffers</function> request.
+For example, if a swap action of <function>Copied</function> is desired,
+but only some of the planes should be copied, a core X
+<function>CopyArea</function> request may be used instead of
+<function>DBESwapBuffers</function>. If
+<function>DBESwapBuffers</function> is included in an idiom, it should
+immediately follow the
+<function>DBEBeginIdiom</function> request. Also, when the
+<function>DBESwapBuffers</function> 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 <function>Untouched</function>, and if a
+<function>PolyFillRectangle</function> using a client clip
+rectangle is done to the window’s back buffer after the
+<function>DBESwapBuffers</function> 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.
+</para>
+<para>
+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
+<function>DBEBeginIdiom</function> request, the idiom
+requests, and <function>DBEEndIdiom</function> request. Usage of these
+functions will ensure best possible performance across a wide
+variety of implementations.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id='C_Language_Binding'>
+<title>C Language Binding</title>
+<para>
+All identifier The header for this extension is <X11/extensions/Xdbe.h>.
+names provided by this header begin with Xdbe.
+</para>
+
+<sect1 id='Types'>
+<title>Types</title>
+
+<para>
+The type <function>XdbeBackBuffer</function> is a <function>Drawable</function>.
+</para>
+
+<para>
+The type <function>XdbeSwapAction</function> can be one of the constants
+<function>XdbeUndefined</function>,
+<function>XdbeBackground</function>,
+<function>XdbeUntouched</function>, or
+<function>XdbeCopied</function>.
+</para>
+
+</sect1>
+
+<sect1 id='C_Functions'>
+<title>C Functions</title>
+<para>
+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
+<function>Status</function> will return nonzero for success and
+zero for failure.
+</para>
+
+<funcsynopsis id='XdbeQueryExtension'>
+<funcprototype>
+ <funcdef>Status <function>XdbeQueryExtension</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>int <parameter> *major_version_return</parameter></paramdef>
+ <paramdef>int <parameter> *minor_version_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeQueryExtension</function> 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.
+</para>
+
+<funcsynopsis id='XdbeGetVisualInfo'>
+<funcprototype>
+ <funcdef>XdbeScreenVisualInfo *<function>XdbeGetVisualInfo</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>Drawable <parameter> *screen_specifiers</parameter></paramdef>
+ <paramdef>int <parameter> *num_screens</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+
+<function>XdbeGetVisualInfo</function> 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
+<function>XdbeScreenVisualInfo</function>
+structures of length num_screens. The nth element in the returned list
+corresponds to the nth drawable in the screen_specifiers list, unless
+
+element in the returned list corresponds to the nth screen of the server,
+starting with screen zero.
+</para>
+
+
+<para>
+The XdbeScreenVisualInfo structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int count number of items in visinfo
+XdbeVisualInfo* visinfo list of visuals and depths for this screen
+</literallayout>
+
+<para>
+The <function>XdbeVisualInfo</function> structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+VisualID visual one visual ID that supports double-buffering
+int depth depth of visual in bits
+int perflevel performance level of visual
+</literallayout>
+
+
+<funcsynopsis>
+<funcprototype>
+ <funcdef>void XdbeFreeVisualInfo <function>XdbeGetVisualInfo</function></funcdef>
+ <paramdef>XdbeScreenVisualInfo <parameter> *visual_info</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeFreeVisualInfo</function> frees the list of
+<function>XdbeScreenVisualInfo</function> returned by
+<function>XdbeGetVisualInfo</function>.
+</para>
+
+
+<funcsynopsis id='XdbeAllocateBackBufferName'>
+<funcprototype>
+ <funcdef>XdbeBackBuffer <function>XdbeAllocateBackBufferName</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>Window <parameter> *window</parameter></paramdef>
+ <paramdef>XdbeSwapAction <parameter> swap_action</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XdbeAllocateBackBufferName</function> 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 <function>XdbeSwapBuffers</function>. The actual swap_action
+used in calls to <function>XdbeSwapBuffers</function> 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.
+</para>
+
+<funcsynopsis id='XdbeDeallocateBackBufferName'>
+<funcprototype>
+ <funcdef>Status <function>XdbeDeallocateBackBufferName</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeDeallocateBackBufferName</function> frees the specified
+drawable ID, buffer, that was obtained via
+<function>XdbeAllocateBackBufferName</function>. The buffer must be a valid
+name for the back buffer of a window, or an
+<function>XdbeBadBuffer</function> error results.
+</para>
+
+<funcsynopsis id='XdbeSwapBuffers'>
+<funcprototype>
+ <funcdef>Status <function>XdbeSwapBuffers</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>XdbeSwapInfo <parameter> *swap_info</parameter></paramdef>
+ <paramdef>int <parameter> num_windows</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeSwapBuffers</function> 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.
+</para>
+<para>
+The XdbeSwapInfo structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window swap_window window for which to swap buffers
+XdbeSwapAction swap_action swap action to use for this swap window
+</literallayout>
+
+<funcsynopsis id='XdbeBeginIdiom'>
+<funcprototype>
+ <funcdef>Status <function>XdbeBeginIdiom</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeBeginIdiom</function> marks the beginning of an idiom
+sequence. See
+<link linkend='Complex_Swap_Actions'>
+<xref linkend='Complex_Swap_Actions'></xref></link>
+for a complete discussion of idioms.
+</para>
+
+<funcsynopsis id='XdbeEndIdiom'>
+<funcprototype>
+ <funcdef>Status <function>XdbeEndIdiom</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeEndIdiom</function> marks the end of an idiom sequence.
+</para>
+
+<funcsynopsis id='XdbeGetBackBufferAttributes'>
+<funcprototype>
+ <funcdef>XdbeBackBufferAttributes *<function>XdbeGetBackBufferAttributes</function></funcdef>
+ <paramdef>Display <parameter> *dpy</parameter></paramdef>
+ <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeGetBackBufferAttributes</function> returns the attributes associated with
+the specified buffer.
+</para>
+<para>
+The XdbeBackBufferAttributes structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window window window that buffer belongs to
+</literallayout>
+
+<para>
+If buffer is not a valid <function>XdbeBackBuffer</function>, window is
+set to None.
+</para>
+<para>
+The returned <function>XdbeBackBufferAttributes</function> structure
+can be freed with the Xlib function <function>XFree</function>.
+</para>
+</sect1>
+
+<sect1 id='Errors'>
+<title>Errors</title>
+<para>
+The <function>XdbeBufferError</function> structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int type
+Display * display Display the event was read from
+XdbeBackBuffer buffer resource id
+unsigned long serial serial number of failed request
+unsigned char error code error base + <function>XdbeBadBuffer</function>
+unsigned char request code Major op-code of failed request
+unsigned char minor code Minor op-code of failed request
+</literallayout>
+</sect1>
+</chapter>
+
+<chapter id='Acknowledgements'>
+<title>Acknowledgements</title>
+
+<para>
+We wish to thank the following individuals who have contributed their time
+and talent toward shaping the DBE specification:
+</para>
+<para>
+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.
+</para>
+<para>
+Mark provided the impetus to start the DBE project. Ian wrote the first draft
+of the specification. David served as architect.
+</para>
+
+</chapter>
+<chapter id='References'>
+<title>References</title>
+<para>
+Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, "Multi-buffering Extension
+Specification Version 3.3."
+</para>
+<para>
+Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins, "X
+Synchronization Extension Version 3.0."
+</para>
+</chapter>
+</book>
Index: libXext-1.3.5-new/specs/shapelib.xml
===================================================================
--- libXext-1.3.5-new/specs/shapelib.xml (nonexistent)
+++ libXext-1.3.5-new/specs/shapelib.xml (revision 5)
@@ -0,0 +1,577 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
+[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="shapelib">
+
+<bookinfo>
+ <title>X Nonrectangular Window Shape Extension Library</title>
+ <subtitle>X Consortium Standard</subtitle>
+ <releaseinfo>X Version 11, Release &fullrelvers;</releaseinfo>
+ <releaseinfo>Version 1.0</releaseinfo>
+ <authorgroup>
+ <author>
+ <firstname>Keith</firstname><surname>Packard</surname>
+ <affiliation><orgname>MIT X Consortium</orgname></affiliation>
+ </author>
+ </authorgroup>
+ <copyright><year>1989</year><holder>X Consortium</holder></copyright>
+
+<legalnotice>
+
+<para>
+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:
+</para>
+
+<para>
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+<para>X Window System is a trademark of The OpenGroup.</para>
+</legalnotice>
+</bookinfo>
+
+<chapter id='overview'>
+<title>Overview</title>
+
+<para>This extension provides arbitrary window and border shapes within
+the X11 protocol.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+</chapter>
+
+<chapter id='description'>
+<title>Description</title>
+
+<para>
+Each window (even with no shapes specified) is defined by two regions: the
+bounding region
+and the
+clip region.
+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.
+</para>
+
+<para>
+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
+default bounding region and the
+default clip region. For a window with
+inside size of <emphasis remap='I'>width</emphasis> by
+<emphasis remap='I'>height</emphasis> and border width
+<emphasis remap='I'>bwidth</emphasis>, the default bounding and clip
+regions are the rectangles (relative to the window origin):
+</para>
+
+<literallayout remap='Ds'>
+bounding.x = -<emphasis remap='I'>bwidth</emphasis>
+bounding.y = -<emphasis remap='I'>bwidth</emphasis>
+bounding.width = <emphasis remap='I'>width</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>
+bounding.height = <emphasis remap='I'>height</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>
+
+clip.x = 0
+clip.y = 0
+clip.width = <emphasis remap='I'>width</emphasis>
+clip.height = <emphasis remap='I'>height</emphasis>
+</literallayout>
+
+<para>
+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
+client bounding region and the
+client clip region. 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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+The effective bounding region 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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+The effective clip region 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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>An InputOnly window can have its bounding region set, but it is a
+Match error to attempt to set a clip region on an
+InputOnly window or to specify its clip region as a source to a request
+in this extension.
+</para>
+
+<para>
+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.
+</para>
+</chapter>
+
+<chapter id='c_language_binding'>
+<title>C Language Binding</title>
+
+<para>
+The C functions provide direct access to the protocol and add no additional
+semantics.
+</para>
+
+<para>The include file for this extension is
+<<symbol role='Pn'>X11/extensions/shape.h</symbol>>.
+The defined shape kinds are
+<function>ShapeBounding</function>
+and
+<function>ShapeClip</function>
+The defined region operations are
+<function>ShapeSet</function>
+<function>ShapeUnion</function>
+<function>ShapeIntersect</function>
+<function>ShapeSubtract</function>
+and
+<function>ShapeInvert</function>.</para>
+
+<funcsynopsis id='xshapequeryextension'>
+<funcprototype>
+<funcdef>Bool<function> XShapeQueryExtension</function></funcdef>
+<paramdef>Display <parameter>*display</parameter></paramdef>
+<paramdef>int <parameter>*event_base</parameter></paramdef>
+<paramdef>int <parameter>*error_base</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeQueryExtension</function>
+returns
+<function>True</function>
+if the specified display supports the SHAPE extension else
+<function>False</function>
+If the extension is supported, *event_base is set to the event number for
+<function>ShapeNotify</function>
+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).
+</para>
+
+<funcsynopsis id='xshapequeryversion'>
+<funcprototype>
+<funcdef>Status<function> XShapeQueryVersion</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>int<parameter> *major_version</parameter></paramdef>
+<paramdef>int<parameter> *minor_version</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeQueryVersion</function>
+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.
+</para>
+
+<funcsynopsis id='xshapecombineregion'>
+<funcprototype>
+<funcdef><function>XShapeCombineRegion</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>int<parameter> region</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+<paramdef>REGION<parameter> *region</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeCombineRegion</function>
+converts the specified region into a list of rectangles and calls
+<function>XShapeCombineRectangles</function>
+</para>
+
+<funcsynopsis id='xshapecombinerectangles'>
+<funcprototype>
+<funcdef><function>XShapeCombineRectangles</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>XRectangle<parameter> *rectangles</parameter></paramdef>
+<paramdef>int<parameter> n_rects</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+<paramdef>int<parameter> ordering</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineRectangles</function>
+performs a
+<function>ShapeRectangles</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapecombinemask'>
+<funcprototype>
+<funcdef><function>XShapeCombineMask</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>int<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>Pixmap<parameter> src</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineMask</function>
+performs a
+<function>ShapeMask</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapecombineshape'>
+<funcprototype>
+<funcdef><function>XShapeCombineShape</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>Window<parameter> src</parameter></paramdef>
+<paramdef>int<parameter> src_kind</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineShape</function>
+performs a
+<function>ShapeCombine</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapeoffsetshape'>
+<funcprototype>
+<funcdef><function>XShapeOffsetShape</function></funcdef>
+<paramdef><parameter>display</parameter></paramdef>
+<paramdef><parameter>dest</parameter></paramdef>
+<paramdef><parameter>dest_kind</parameter></paramdef>
+<paramdef><parameter>x_off</parameter></paramdef>
+<paramdef><parameter>y_off</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeOffsetShape</function>
+performs a
+<function>ShapeOffset</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapequeryextents'>
+<funcprototype>
+<funcdef>Status <function>XShapeQueryExtents</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>Bool<parameter> *bounding_shaped</parameter></paramdef>
+<paramdef>int<parameter> *x_bounding</parameter></paramdef>
+<paramdef>int<parameter> *y_bounding</parameter></paramdef>
+<paramdef>unsigned int<parameter> *w_bounding</parameter></paramdef>
+<paramdef>unsigned int<parameter> *h_bounding</parameter></paramdef>
+<paramdef>Bool<parameter> *clip_shaped</parameter></paramdef>
+<paramdef>int<parameter> *x_clip</parameter></paramdef>
+<paramdef>int<parameter> *y_clip</parameter></paramdef>
+<paramdef>unsigned int<parameter> *w_clip</parameter></paramdef>
+<paramdef>unsigned int<parameter> *h_clip</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeQueryExtents</function>
+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.
+</para>
+
+<para>
+If the extension is supported, a nonzero value is returned; otherwise,
+zero is returned.
+</para>
+
+<funcsynopsis id='xshapeselectinput'>
+<funcprototype>
+<funcdef><function>XShapeSelectInput</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>unsigned long<parameter> mask</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+To make this extension more compatible with other interfaces, although
+only one event type can be selected via the extension,
+<function>XShapeSelectInput</function>
+provides a general mechanism similar to the standard Xlib binding for
+window events. A mask value has been defined,
+<function>ShapeNotifyMask</function>
+that is the only valid bit in mask that may be specified.
+The structure for this event is defined as follows:
+</para>
+
+<literallayout remap='Ds'>
+typedef struct {
+ int type; /* of event */
+ unsigned long serial; /* # 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 */
+ 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;
+</literallayout>
+
+<funcsynopsis id='xshapeinputselected'>
+<funcprototype>
+<funcdef>unsigned long <function>XShapeInputSelected</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeInputSelected</function>
+returns the current input mask for extension events on the specified
+window; the value returned if
+<function>ShapeNotify</function>
+is selected for is
+<function>ShapeNotifyMask</function>
+otherwise, it returns zero.
+If the extension is not supported, it returns zero.
+</para>
+
+<funcsynopsis id='xshapegetrectangles'>
+<funcprototype>
+<funcdef>XRectangle<function> *XShapeGetRectangles</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>int<parameter> kind</parameter></paramdef>
+<paramdef>int<parameter> *count</parameter></paramdef>
+<paramdef>int<parameter> *ordering</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is not supported,
+<function>XShapeGetRectangles</function>
+returns NULL. Otherwise, it returns a list of rectangles that describe the
+region specified by kind.
+</para>
+</chapter>
+
+<glossary id='glossary'>
+
+<glossentry id='bounding_region'>
+ <glossterm>bounding region</glossterm>
+ <glossdef><para>The area of the parent window that this window will occupy.
+This area is divided into two parts: the border and the interior.</para>
+ </glossdef>
+</glossentry>
+
+<glossentry id='clip_region'>
+ <glossterm>clip region</glossterm>
+ <glossdef><para>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.</para></glossdef>
+</glossentry>
+
+<glossentry id='default_bounding_region'>
+ <glossterm>default bounding region</glossterm>
+ <glossdef><para>The rectangular area, as described by the core protocol
+window size, that covers the interior of the window and its border.</para>
+ </glossdef>
+</glossentry>
+
+<glossentry id='default_clip_region'>
+ <glossterm>default clip region</glossterm>
+ <glossdef><para>The rectangular area, as described by the core protocol
+window size, that covers the interior of the window and excludes the border.
+ </para></glossdef>
+</glossentry>
+
+<glossentry id='client_bounding_region'>
+ <glossterm>client bounding region</glossterm>
+ <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
+<function>ShapeBounding</function>
+This region is used in conjunction with the default bounding region
+to produce the effective bounding region.</para></glossdef>
+</glossentry>
+
+<glossentry id='client_clip_region'>
+ <glossterm>client clip region</glossterm>
+ <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
+<function>ShapeClip</function>
+This region is used in conjunction with the default clip region
+and the client bounding region to produce the effective clip region.</para>
+ </glossdef>
+</glossentry>
+
+<glossentry id='effective_bounding_region'>
+ <glossterm>effective bounding region</glossterm>
+ <glossdef><para>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.</para>
+ </glossdef>
+</glossentry>
+
+<glossentry id='effective_clip_region'>
+ <glossterm>effective clip region</glossterm>
+ <glossdef><para>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.</para>
+ </glossdef>
+</glossentry>
+</glossary>
+</book>
Index: libXext-1.3.5-new/specs
===================================================================
--- libXext-1.3.5-new/specs (nonexistent)
+++ libXext-1.3.5-new/specs (revision 5)
Property changes on: libXext-1.3.5-new/specs
___________________________________________________________________
Added: svn:ignore
## -0,0 +1,73 ##
+
+# install dir
+dist
+
+# Target build dirs
+.a1x-newlib
+.a2x-newlib
+.at91sam7s-newlib
+
+.build-machine
+
+.a1x-glibc
+.a2x-glibc
+.h3-glibc
+.h5-glibc
+.i586-glibc
+.i686-glibc
+.imx6-glibc
+.jz47xx-glibc
+.makefile
+.am335x-glibc
+.omap543x-glibc
+.p5600-glibc
+.power8-glibc
+.power8le-glibc
+.power9-glibc
+.power9le-glibc
+.m1000-glibc
+.riscv64-glibc
+.rk328x-glibc
+.rk33xx-glibc
+.rk339x-glibc
+.s8xx-glibc
+.s9xx-glibc
+.x86_64-glibc
+
+# Hidden files (each file)
+.makefile
+.dist
+.rootfs
+
+# src & hw requires
+.src_requires
+.src_requires_depend
+.requires
+.requires_depend
+
+# Tarballs
+*.gz
+*.bz2
+*.lz
+*.xz
+*.tgz
+*.txz
+
+# Signatures
+*.asc
+*.sig
+*.sign
+*.sha1sum
+
+# Patches
+*.patch
+
+# Descriptions
+*.dsc
+*.txt
+
+# Default linux config files
+*.defconfig
+
+# backup copies
+*~
Index: libXext-1.3.5-new
===================================================================
--- libXext-1.3.5-new (nonexistent)
+++ libXext-1.3.5-new (revision 5)
Property changes on: libXext-1.3.5-new
___________________________________________________________________
Added: svn:ignore
## -0,0 +1,73 ##
+
+# install dir
+dist
+
+# Target build dirs
+.a1x-newlib
+.a2x-newlib
+.at91sam7s-newlib
+
+.build-machine
+
+.a1x-glibc
+.a2x-glibc
+.h3-glibc
+.h5-glibc
+.i586-glibc
+.i686-glibc
+.imx6-glibc
+.jz47xx-glibc
+.makefile
+.am335x-glibc
+.omap543x-glibc
+.p5600-glibc
+.power8-glibc
+.power8le-glibc
+.power9-glibc
+.power9le-glibc
+.m1000-glibc
+.riscv64-glibc
+.rk328x-glibc
+.rk33xx-glibc
+.rk339x-glibc
+.s8xx-glibc
+.s9xx-glibc
+.x86_64-glibc
+
+# Hidden files (each file)
+.makefile
+.dist
+.rootfs
+
+# src & hw requires
+.src_requires
+.src_requires_depend
+.requires
+.requires_depend
+
+# Tarballs
+*.gz
+*.bz2
+*.lz
+*.xz
+*.tgz
+*.txz
+
+# Signatures
+*.asc
+*.sig
+*.sign
+*.sha1sum
+
+# Patches
+*.patch
+
+# Descriptions
+*.dsc
+*.txt
+
+# Default linux config files
+*.defconfig
+
+# backup copies
+*~
Index: .
===================================================================
--- . (nonexistent)
+++ . (revision 5)
Property changes on: .
___________________________________________________________________
Added: svn:ignore
## -0,0 +1,73 ##
+
+# install dir
+dist
+
+# Target build dirs
+.a1x-newlib
+.a2x-newlib
+.at91sam7s-newlib
+
+.build-machine
+
+.a1x-glibc
+.a2x-glibc
+.h3-glibc
+.h5-glibc
+.i586-glibc
+.i686-glibc
+.imx6-glibc
+.jz47xx-glibc
+.makefile
+.am335x-glibc
+.omap543x-glibc
+.p5600-glibc
+.power8-glibc
+.power8le-glibc
+.power9-glibc
+.power9le-glibc
+.m1000-glibc
+.riscv64-glibc
+.rk328x-glibc
+.rk33xx-glibc
+.rk339x-glibc
+.s8xx-glibc
+.s9xx-glibc
+.x86_64-glibc
+
+# Hidden files (each file)
+.makefile
+.dist
+.rootfs
+
+# src & hw requires
+.src_requires
+.src_requires_depend
+.requires
+.requires_depend
+
+# Tarballs
+*.gz
+*.bz2
+*.lz
+*.xz
+*.tgz
+*.txz
+
+# Signatures
+*.asc
+*.sig
+*.sign
+*.sha1sum
+
+# Patches
+*.patch
+
+# Descriptions
+*.dsc
+*.txt
+
+# Default linux config files
+*.defconfig
+
+# backup copies
+*~
Radix cross Linux
The main Radix cross Linux repository contains the build scripts of packages, which have the most complete and common functionality for desktop machines
452 Commits
2 Branches
1 Tag