From 0e1ac54142d49051da9a74f37a792225a4e8d7b0 Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 5 Jun 2011 16:00:23 +0200 Subject: libX11 libXext libXmu mesa xkeyboard-config git update Jun 2011 --- libX11/specs/i18n/framework/framework.xml | 3240 ++++++++++++------------ libX11/specs/i18n/trans/trans.xml | 14 +- libXext/specs/dbelib.xml | 1456 +++++------ libXext/specs/dpmslib.xml | 838 +++--- libXext/specs/shapelib.xml | 1154 ++++----- libXext/specs/synclib.xml | 1626 ++++++------ libXmu/doc/Xmu.xml | 12 +- mesalib/src/glsl/glsl_parser_extras.cpp | 2 +- mesalib/src/glsl/ir_print_visitor.cpp | 2 +- mesalib/src/mesa/drivers/dri/Makefile.defines | 34 + mesalib/src/mesa/drivers/dri/Makefile.targets | 78 + xorg-server/xkeyboard-config/rules/base.xml.in | 7 +- xorg-server/xkeyboard-config/rules/xkb.dtd | 5 +- xorg-server/xkeyboard-config/symbols/de | 15 - 14 files changed, 4289 insertions(+), 4194 deletions(-) create mode 100644 mesalib/src/mesa/drivers/dri/Makefile.defines create mode 100644 mesalib/src/mesa/drivers/dri/Makefile.targets diff --git a/libX11/specs/i18n/framework/framework.xml b/libX11/specs/i18n/framework/framework.xml index ab1dac6b6..97a8264e9 100644 --- a/libX11/specs/i18n/framework/framework.xml +++ b/libX11/specs/i18n/framework/framework.xml @@ -1,1620 +1,1620 @@ - - - - - - - X11R6 Sample Implementation Frame Work - X Version 11, Release 7 - - - KatsuhisaYano - TOSHIBA Corporation - - - YoshioHoriuchi - IBM Japan - - - 1994TOSHIBA Corporation - 1994IBM Corporation - - - - -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. TOSHIBA Corporation and -IBM Corporation 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. - - - -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 Open Group shall not -be used in advertising or otherwise to promote the sale, use or other dealings -in this Software without prior written authorization from X Consortium. - - -X Window System is a trademark of The Open Group. - - - - - -Framework - -Preface - -This document proposes to define the structures, methods and their -signatures that are expected to be common to all locale dependent -functions within the Xlib sample implementation. The following -illustration (Fig.1) is proposed to outline the separating of -the components within the sample implementation. - - - -Preface drawing. - - - - - - - Frame work of Locale Service API Proposal - - - -Generally speaking, the internationalized portion of Xlib (Locale -Dependent X, LDX) consists of three objects; -locale (LC) , input method (IM) and output method (OM). -The LC provides a set of information that depends on user's language -environment. The IM manages text inputing, and the OM manages text -drawing. Both IM and OM highly depend on LC data. - - - -In X11R5, there are two sample implementations, Ximp and Xsi, for -Xlib internationalization. But in both implementations, IM and OM -actually refer the private extension of LC. It breaks coexistence -of these two sample implementations. For example, if a user creates -a new OM for special purpose as a part of Ximp, it will not work with -Xsi. - - - -As a solution of this problem, we propose to define the standard -APIs between these three objects, and define the structure that are -common to these objects. - - - - -Objective - - - - -Explain the current X11R6 sample implementation - - - - -Document the common set of locale dependent interfaces - - - - -Provide more flexible pluggable layer - - - - - - -Locale Object Binding Functions - - - -This chapter describes functions related locale object binding for -implementing the pluggable layer. - - - -A locale loader is an entry point for locale object, which -instantiates XLCd object and binds locale methods with specified -locale name. The behavior of loader is implementation dependent. -And, what kind of loaders are available is also implementation -dependent. - - - - -The loader is called in -_XOpenLC, -but caller of -_XOpenLC -does not need to care about its inside. For example, if the loader is -implemented with dynamic load functions, and the dynamic module is -expected to be unloaded when the corresponding XLCd is freed, -close methods of XLCdMethods should handle unloading. - - - -Initializing a locale loader list - - -void _XlcInitLoader - - - -The -_XlcInitLoader -function initializes the locale loader list with vendor specific -manner. Each loader is registered with calling -_XlcAddLoader. -The number of loaders and their order in the loader list is -implementation dependent. - - - -Add a loader - - - -typedef XLCd (*XLCdLoadProc)(name); - char *name; - -typedef int XlcPosition; - -#define XlcHead -#define XlcTail - - - - - Bool _XlcAddLoader - XLCdLoadProc proc - XlcPosition position - - - - -The -_XlcAddLoader -function registers the specified locale loader "proc" to the -internal loader list. The position specifies that the loader -"proc" should be placed in the top of the loader list(XlcHead) -or last(XlcTail). - - - -The object loader is called from the top of the loader list in order, -when calling time. - - - -Remove a loader - - - - - void _XlcRemoveLoader - XLCdLoadProc proc - - - - -The -_XlcRemoveLoader -function removes the locale loader specified by "proc" from the -loader list. - - - -Current implementation provides following locale loaders; - - - -_XlcDefaultLoader -_XlcGenericLoader -_XlcEucLoader -_XlcSjisLoader -_XlcUtfLoader -_XaixOsDynamicLoad - - - - - -Locale Method Interface - - -This chapter describes the locale method API, which is a set of -accessible functions from both IM and OM parts. -The locale method API provides the functionalities; obtaining locale -dependent information, handling charset, converting text, etc. - - - -As a result of using these APIs instead of accessing vender private -extension of the locale object, we can keep locale, IM and OM -independently each other. - - - - - -Locale Method Functions - -Open a Locale Method - - - - - XLCd _XOpenLC - char *name - - - - -The -_XOpenLC -function opens a locale method which corresponds to the -specified locale name. -_XOpenLC -calls a locale object loader, which is registered via -_XlcAddLoader into the internal loader list. If the called loader -is valid and successfully opens a locale, -_XOpenLC -returns the XLCd. If the loader is invalid or failed to open a locale, -_XOpenLC -calls the next loader. If all registered loaders cannot open a locale, -_XOpenLC -returns NULL. - - -XLCd _XlcCurrentLC - - -The -_XlcCurrentLC -function returns an XLCd that are bound to current locale. - - - -Close a Locale Method - - - - - void _XCloseLC - XLCd lcd - - - - - -The -_XCloseLC -function close a locale method the specified lcd. - - - -Obtain Locale Method values - - - - - char *_XGetLCValues - XLCd lcd - - - - -The -_XGetLCValues -function returns NULL if no error occurred; otherwise, it returns the -name of the first argument that could not be obtained. -The following values are defined as standard arguments. Other values -are implementation dependent. - - - - - - - - - - Name - Type - Description - - - - - XlcNCodeset - char* - codeset part of locale name - - - XlcNDefaultString - char* - XDefaultString() - - - XlcNEncodingName - char* - encoding name - - - XlcNLanguage - char* - language part of locale name - - - XlcNMbCurMax - int - ANSI C MB_CUR_MAX - - - XlcNStateDependentEncoding - Bool - is state-dependent encoding or not - - - XlcNTerritory - char* - territory part of locale name - - - - - - - - -Charset functions - -The XlcCharSet is an identifier which represents a subset of characters -(character set) in the locale object. - - - -typedef enum { - XlcUnknown, XlcC0, XlcGL, XlcC1, XlcGR, XlcGLGR, XlcOther -} XlcSide; - -typedef struct _XlcCharSetRec *XlcCharSet; - -typedef struct { - char *name; - XPointer value; -} XlcArg, *XlcArgList; - -typedef char* (*XlcGetCSValuesProc)(charset, args, num_args); - XlcCharSet charset; - XlcArgList args; - int num_args; - -typedef struct _XlcCharSetRec { - char *name; - XrmQuark xrm_name; - char *encoding_name; - XrmQuark xrm_encoding_name; - XlcSide side; - int char_size; - int set_size; - char *ct_sequence; - XlcGetCSValuesProc get_values; -} XlcCharSetRec; - - - -Get an XlcCharSet - - - - - XlcCharSet _XlcGetCharSet - char *name - - - - -The -_XlcGetCharSet -function gets an XlcCharSet which corresponds to the charset name -specified by "name". -_XlcGetCharSet -returns NULL, if no XlcCharSet bound to specified "name". - - - -The following character sets are pre-registered. - - - - - - - - - Name - Description - - - - - ISO8859-1:GL - 7-bit ASCII graphics (ANSI X3.4-1968), - - - - Left half of ISO 8859 sets - - - JISX0201.1976-0:GL - Left half of JIS X0201-1976 (reaffirmed 1984), - - - - 8-Bit Alphanumeric-Katakana Code - - - ISO8859-1:GR - Right half of ISO 8859-1, Latin alphabet No. 1 - - - ISO8859-2:GR - Right half of ISO 8859-2, Latin alphabet No. 2 - - - ISO8859-3:GR - Right half of ISO 8859-3, Latin alphabet No. 3 - - - ISO8859-4:GR - Right half of ISO 8859-4, Latin alphabet No. 4 - - - ISO8859-7:GR - Right half of ISO 8859-7, Latin/Greek alphabet - - - ISO8859-6:GR - Right half of ISO 8859-6, Latin/Arabic alphabet - - - ISO8859-8:GR - Right half of ISO 8859-8, Latin/Hebrew alphabet - - - ISO8859-5:GR - Right half of ISO 8859-5, Latin/Cyrillic alphabet - - - ISO8859-9:GR - Right half of ISO 8859-9, Latin alphabet No. 5 - - - JISX0201.1976-0:GR - Right half of JIS X0201-1976 (reaffirmed 1984), - - - - 8-Bit Alphanumeric-Katakana Code - - - GB2312.1980-0:GL - GB2312-1980, China (PRC) Hanzi defined as GL - - - GB2312.1980-0:GR - GB2312-1980, China (PRC) Hanzi defined as GR - - - JISX0208.1983-0:GL - JIS X0208-1983, Japanese Graphic Character Set - - - - defined as GL - - - JISX0208.1983-0:GR - JIS X0208-1983, Japanese Graphic Character Set - - - - defined as GR - - - KSC5601.1987-0:GL - KS C5601-1987, Korean Graphic Character Set - - - - defined as GL - - - KSC5601.1987-0:GR - KS C5601-1987, Korean Graphic Character Set - - - - defined as GR - - - JISX0212.1990-0:GL - JIS X0212-1990, Japanese Graphic Character Set - - - - defined as GL - - - JISX0212.1990-0:GR - JIS X0212-1990, Japanese Graphic Character Set - - - - defined as GR - - - - - - -Add an XlcCharSet - - - - - Bool _XlcAddCharSet - XlcCharSet charset - - - - -The -_XlcAddCharSet -function registers XlcCharSet specified by "charset". - - - - - -Obtain Character Set values - - - - - char * _XlcGetCSValues - XlcCharSet charset - ... - - - - -The -_XlcGetCSValues -function returns NULL if no error occurred; -otherwise, it returns the name of the first argument that could not -be obtained. The following values are defined as standard arguments. -Other values are implementation dependent. - - - - - - - - - - Name - Type - Description - - - - - XlcNName - char* - charset name - - - XlcNEncodingName - char* - XLFD CharSet Registry and Encoding - - - XlcNSide - XlcSide - charset side (GL, GR, ...) - - - XlcNCharSize - int - number of octets per character - - - XlcNSetSize - int - number of character sets - - - XlcNControlSequence - char* - control sequence of Compound Text - - - - - - - - -Converter Functions - -We provide a set of the common converter APIs, that are independent -from both of source and destination text type. - - - -typedef struct _XlcConvRec *XlcConv; - -typedef void (*XlcCloseConverterProc)(conv); - XlcConv conv; - -typedef int (*XlcConvertProc)(conv, from, from_left, to, to_left, args, num_args); - XlcConv conv; - XPointer *from; - int *from_left; - XPointer *to; - int *to_left; - XPointer *args; - int num_args; - -typedef void (*XlcResetConverterProc)(conv); - XlcConv conv; - -typedef struct _XlcConvMethodsRec { - XlcCloseConverterProc close; - XlcConvertProc convert; - XlcResetConverterProc reset; -} XlcConvMethodsRec, *XlcConvMethods; - -typedef struct _XlcConvRec { - XlcConvMethods methods; - XPointer state; -} XlcConvRec; - - - -Open a converter - - - - - XlcConv _XlcOpenConverter - XLCd from_lcd - char *from_type - XLCd to_lcd - char *to_type - - - - -_XlcOpenConverter -function opens the converter which converts a text from specified -"from_type" to specified "to_type" encoding. If the -function cannot find proper converter or cannot open a corresponding -converter, it returns NULL. Otherwise, it returns the conversion -descriptor. - - - -The following types are pre-defined. Other types are implementation -dependent. - - - - - - - - - - - Name - Type - Description - Arguments - - - - - XlcNMultiByte - char * - multibyte - - - - - XlcNWideChar - wchar_t * - wide character - - - - - XlcNCompoundText - char * - COMPOUND_TEXT - - - - - XlcNString - char * - STRING - - - - - XlcNCharSet - char * - per charset - XlcCharSet - - - XlcNChar - char * - per character - XlcCharSet - - - - - - -Close a converter - - - - - void _XlcCloseConverter - XlcConv conv - - - - -The -_XlcCloseConverter -function closes the specified converter "conv". - - - -Code conversion - - - - - int _XlcConvert - XlcConv conv - XPointer *from - int *from_left - XPointer *to - int *to_left - XPointer *args - int num_args - - - - -The -_XlcConvert -function converts a sequence of characters from one type, in the array -specified by "from", into a sequence of corresponding characters -in another type, in the array specified by "to". The types are -those specified in the -_XlcOpenConverter() -call that returned the conversion descriptor, "conv". -The arguments "from", "from_left", "to" and -"to_left" have the same specification of XPG4 iconv function. - - - -For state-dependent encodings, the conversion descriptor "conv" -is placed into its initial shift state by a call for which "from" -is a NULL pointer, or for which "from" points to a null pointer. - - - -The following 2 converters prepared by locale returns appropriate -charset (XlcCharSet) in an area pointed by args[0]. - - - - - - - - - - From - To - Description - - - - - XlcNMultiByte - XlcNCharSet - Segmentation (Decomposing) - - - XlcNWideChar - XlcNCharSet - Segmentation (Decomposing) - - - - - - -The conversion, from XlcNMultiByte/XlcNWideChar to XlcNCharSet, -extracts a segment which has same charset encoding characters. -More than one segment cannot be converted in a call. - - - -Reset a converter - - - - - void _XlcResetConverter - XlcConv conv - - - - -The -_XlcResetConverter -function reset the specified converter "conv". - - - -Register a converter - - - -typedef XlcConv (*XlcOpenConverterProc)(from_lcd, from_type, to_lcd, to_type); - XLCd from_lcd; - char *from_type; - XLCd to_lcd; - char *to_type; - - - - - Bool _XlcSetConverter - XLCd from_lcd - char *from - XLCd to_lcd - char *to - XlcOpenConverterProc converter - - - - -The XlcSetConverter function registers a converter which convert -from "from_type" to "to_type" into the converter list -(in the specified XLCd). - - - - -X Locale Database functions - -X Locale Database contains the subset of user's environment that -depends on language. The following APIs are provided for accessing -X Locale Database and other locale relative files. - - - -For more detail about X Locale Database, please refer -X Locale Database Definition document. - - - -Get a resource from database - - - - - void _XlcGetResource - XLCd lcd - char *category - char *class - char ***value - int *count - - - - -The -_XlcGetResource -function obtains a locale dependent data which is associated with the -locale of specified "lcd". -The locale data is provided by system locale or by X Locale Database -file, and what kind of data is available is implementation dependent. - - - -The specified "category" and "class" are used for -finding out the objective locale data. - - - -The returned value is returned in value argument in string list form, -and the returned count shows the number of strings in the value. - - - -The returned value is owned by locale method, and should not be modified -or freed by caller. - - - -Get a locale relative file name - - - - - char *_XlcFileName - XLCd lcd - char *category - - - - -The -_XlcFileName -functions returns a file name which is bound to the specified "lcd" -and "category", as a null-terminated string. If no file name can -be found, or there is no readable file for the found file name, -_XlcFileName -returns NULL. The returned file name should be freed by caller. - - - -The rule for searching a file name is implementation dependent. -In current implementation, -_XlcFileName -uses "{category}.dir" file as mapping table, which has pairs of -strings, a full locale name and a corresponding file name. - - - - - -Utility Functions - - -Compare Latin-1 strings - - - - - int _XlcCompareISOLatin1 - char*str1, *str2 - - - - - - int _XlcNCompareISOLatin1 - char*str1, *str2 - int len - - - - -The -_XlcCompareIsoLatin1 -function to compares two ISO-8859-1 strings. Bytes representing ASCII lower -case letters are converted to upper case before making the comparison. -The value returned is an integer less than, equal to, or greater than -zero, depending on whether "str1" is lexicographicly less than, -equal to, or greater than "str2". - - - -The -_XlcNCompareIsoLatin1 -function is identical to -_XlcCompareISOLatin1, -except that at most "len" bytes are compared. - - - -Resource Utility - - - - - int XlcNumber - ArrayType array - - - - -Similar to XtNumber. - - - - - void _XlcCopyFromArg - char *src - char *dst - int size - - - - - - void _XlcCopyToArg - char *src - char **dst - int size - - - - -Similar to -_XtCopyFromArg -and -_XtCopyToArg. - - - - - void _XlcCountVaList - va_list var - int *count_ret - - - - -Similar to -_XtCountVaList. - - - - - void _XlcVaToArgList - va_list var - int count - XlcArgList *args_ret - - - - -Similar to -_XtVaToArgList. - - - -typedef struct _XlcResource { - char *name; - XrmQuark xrm_name; - int size; - int offset; - unsigned long mask; -} XlcResource, *XlcResourceList; - - - -#define XlcCreateMask (1L<<0) -#define XlcDefaultMask (1L<<1) -#define XlcGetMask (1L<<2) -#define XlcSetMask (1L<<3) -#define XlcIgnoreMask (1L<<4) - - - - - void _XlcCompileResourceList - XlcResourceList resources - int num_resources - - - - -Similar to -_XtCompileResourceList. - - - - - char * _XlcGetValues - XPointer base - XlcResourceList resources - int num_resources - XlcArgList args - int num_args - unsignedlong mask - - - - -Similar to XtGetSubvalues. - - - - - char * _XlcSetValues - XPointer base - XlcResourceList resources - int num_resources - XlcArgList args - int num_args - unsignedlong mask - - - - -Similar to XtSetSubvalues. - - - -ANSI C Compatible Functions - - - -The following are ANSI C/MSE Compatible Functions for non-ANSI C environment. - - - - - int _Xmblen - char *str - int len - - - - -The -_Xmblen -function returns the number of characters pointed to by "str". -Only "len" bytes in "str" are used in determining the -character count returned. "Str" may point at characters from -any valid codeset in the current locale. - - - -The call -_Xmblen -is equivalent to -_Xmbtowc(_Xmbtowc((wchar_t*)NULL, str, len)) - - - - - int _Xmbtowc - wchar_t *wstr - char *str - int len - - - - -The -_Xmbtowc -function converts the character(s) pointed to by "str" -to their wide character representation(s) pointed to by "wstr". -"Len" is the number of bytes in "str" to be converted. -The return value is the number of characters converted. - - - -The call -_Xmbtowc -is equivalent to -_Xlcmbtowc((XLCd)NULL, wstr, str, len) - - - - - int _Xlcmbtowc - XLCd lcd - wchar_t *wstr - char *str - int len - - - - -The -_Xlcmbtowc -function is identical to -_Xmbtowc, -except that it requires the "lcd" argument. If "lcd" -is (XLCd) NULL, -_Xlcmbtowc, -calls -_XlcCurrentLC -to determine the current locale. - - - - - int _Xwctomb - char *str - wchar_t wc - - - - -The -_Xwctomb -function converts a single wide character pointed to by "wc" to -its multibyte representation pointed to by "str". -On success, the return value is 1. - - - -The call -_Xwctomb -is equivalent to -_Xlcwctomb((XLCd)NULL, str, wstr) - - - - - int _Xlcwctomb - XLCd lcd - char *str - wchar_t wc - - - - -The -_Xlcwctomb -function is identical to _Xwctomb, except that it requires the -"lcd" argument. If "lcd" is (XLCd) NULL, -_Xlcwctomb, -calls -_XlcCurrentLC -to determine the current locale. - - - - - int _Xmbstowcs - wchar_t *wstr - char *str - int len - - - - -The -_Xmbstowcs -function converts the NULL-terminated string pointed to by "str" -to its wide character string representation pointed to by "wstr". -"Len" is the number of characters in "str" to be converted. - - - -The call -_Xmbstowcs -is equivalent to -_Xlcmbstowcs((XLCd)NULL, wstr, str, len) - - - - - int _Xlcmbstowcs - XLCd lcd - wchar_t *wstr - char *str - int len - - - - -The -_Xlcmbstowcs -function is identical to _Xmbstowcs, except that it requires the -"lcd" argument. If "lcd" is (XLCd) NULL, -_Xlcmbstowcs, -calls -_XlcCurrentLC -to determine the current locale. - - - - - int _Xwcstombs - char *str - wchar_t *wstr - int len - - - - -The -_Xwcstombs -function converts the (wchar_t) NULL terminated wide character string -pointed to by "wstr" to the NULL terminated multibyte string -pointed to by "str". - - - -The call -_Xwcstombs -is equivalent to -_Xlcwcstombs((XLCd)NULL, str, wstr, len) - - - - - int _Xlcwcstombs - XLCd lcd - char *str - wchar_t *wstr - int len - - - - -The -_Xlcwcstombs -function is identical to _Xwcstombs, except that it requires the -"lcd" argument. If "lcd" is (XLCd) NULL, -_Xlcwcstombs, -calls -_XlcCurrentLC -to determine the current locale. - - - - - int _Xwcslen - wchar_t *wstr - - - - -The -_Xwcslen -function returns the count of wide characters in the (wchar_t) NULL -terminated wide character string pointed to by "wstr". - - - - - wchar_t * _Xwcscpy - wchar_t *wstr1 - wchar_t *wstr2 - - - - - - wchar_t * _Xwcsncpy - wchar_t *wstr1 - wchar_t *wstr2 - int len - - - - -The -_Xwcscpy -function copies the (wchar_t) NULL terminated wide character string -pointed to by "wstr2" to the object pointed at by "wstr1". -"Wstr1" is (wchar_t) NULL terminated. The return value is a -pointer to "wstr1". - - - -The -_Xwcsncpy -function is identical to -_Xwcscpy, -except that it copies "len" wide characters from the object -pointed to by "wstr2" to the object pointed to "wstr1". - - - - - int _Xwcscmp - wchar_t*wstr1, *wstr2 - - - - - - int _Xwcsncmp - wchar_t*wstr1, *wstr2 - int len - - - - -The -_Xwcscmp -function compares two (wchar_t) NULL terminated wide character strings. -The value returned is an integer less than, equal to, or greater than zero, -depending on whether "wstr1" is lexicographicly less then, equal to, -or greater than "str2". - - - -The -_Xwcsncmp -function is identical to -_XlcCompareISOLatin1, -except that at most "len" wide characters are compared. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + X11R6 Sample Implementation Frame Work + X Version 11, Release 7 + + + KatsuhisaYano + TOSHIBA Corporation + + + YoshioHoriuchi + IBM Japan + + + 1994TOSHIBA Corporation + 1994IBM Corporation + + + + +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. TOSHIBA Corporation and +IBM Corporation 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. + + + +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 Open Group shall not +be used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from X Consortium. + + +X Window System is a trademark of The Open Group. + + + + + +Framework + +Preface + +This document proposes to define the structures, methods and their +signatures that are expected to be common to all locale dependent +functions within the Xlib sample implementation. The following +illustration (Fig.1) is proposed to outline the separating of +the components within the sample implementation. + + + +Preface drawing. + + + + + + + Frame work of Locale Service API Proposal + + + +Generally speaking, the internationalized portion of Xlib (Locale +Dependent X, LDX) consists of three objects; +locale (LC) , input method (IM) and output method (OM). +The LC provides a set of information that depends on user's language +environment. The IM manages text inputing, and the OM manages text +drawing. Both IM and OM highly depend on LC data. + + + +In X11R5, there are two sample implementations, Ximp and Xsi, for +Xlib internationalization. But in both implementations, IM and OM +actually refer the private extension of LC. It breaks coexistence +of these two sample implementations. For example, if a user creates +a new OM for special purpose as a part of Ximp, it will not work with +Xsi. + + + +As a solution of this problem, we propose to define the standard +APIs between these three objects, and define the structure that are +common to these objects. + + + + +Objective + + + + +Explain the current X11R6 sample implementation + + + + +Document the common set of locale dependent interfaces + + + + +Provide more flexible pluggable layer + + + + + + +Locale Object Binding Functions + + + +This chapter describes functions related locale object binding for +implementing the pluggable layer. + + + +A locale loader is an entry point for locale object, which +instantiates XLCd object and binds locale methods with specified +locale name. The behavior of loader is implementation dependent. +And, what kind of loaders are available is also implementation +dependent. + + + + +The loader is called in +_XOpenLC, +but caller of +_XOpenLC +does not need to care about its inside. For example, if the loader is +implemented with dynamic load functions, and the dynamic module is +expected to be unloaded when the corresponding XLCd is freed, +close methods of XLCdMethods should handle unloading. + + + +Initializing a locale loader list + + +void _XlcInitLoader + + + +The +_XlcInitLoader +function initializes the locale loader list with vendor specific +manner. Each loader is registered with calling +_XlcAddLoader. +The number of loaders and their order in the loader list is +implementation dependent. + + + +Add a loader + + + +typedef XLCd (*XLCdLoadProc)(name); + char *name; + +typedef int XlcPosition; + +#define XlcHead +#define XlcTail + + + + + Bool _XlcAddLoader + XLCdLoadProc proc + XlcPosition position + + + + +The +_XlcAddLoader +function registers the specified locale loader "proc" to the +internal loader list. The position specifies that the loader +"proc" should be placed in the top of the loader list(XlcHead) +or last(XlcTail). + + + +The object loader is called from the top of the loader list in order, +when calling time. + + + +Remove a loader + + + + + void _XlcRemoveLoader + XLCdLoadProc proc + + + + +The +_XlcRemoveLoader +function removes the locale loader specified by "proc" from the +loader list. + + + +Current implementation provides following locale loaders; + + + +_XlcDefaultLoader +_XlcGenericLoader +_XlcEucLoader +_XlcSjisLoader +_XlcUtfLoader +_XaixOsDynamicLoad + + + + + +Locale Method Interface + + +This chapter describes the locale method API, which is a set of +accessible functions from both IM and OM parts. +The locale method API provides the functionalities; obtaining locale +dependent information, handling charset, converting text, etc. + + + +As a result of using these APIs instead of accessing vender private +extension of the locale object, we can keep locale, IM and OM +independently each other. + + + + + +Locale Method Functions + +Open a Locale Method + + + + + XLCd _XOpenLC + char *name + + + + +The +_XOpenLC +function opens a locale method which corresponds to the +specified locale name. +_XOpenLC +calls a locale object loader, which is registered via +_XlcAddLoader into the internal loader list. If the called loader +is valid and successfully opens a locale, +_XOpenLC +returns the XLCd. If the loader is invalid or failed to open a locale, +_XOpenLC +calls the next loader. If all registered loaders cannot open a locale, +_XOpenLC +returns NULL. + + +XLCd _XlcCurrentLC + + +The +_XlcCurrentLC +function returns an XLCd that are bound to current locale. + + + +Close a Locale Method + + + + + void _XCloseLC + XLCd lcd + + + + + +The +_XCloseLC +function close a locale method the specified lcd. + + + +Obtain Locale Method values + + + + + char *_XGetLCValues + XLCd lcd + + + + +The +_XGetLCValues +function returns NULL if no error occurred; otherwise, it returns the +name of the first argument that could not be obtained. +The following values are defined as standard arguments. Other values +are implementation dependent. + + + + + + + + + + Name + Type + Description + + + + + XlcNCodeset + char* + codeset part of locale name + + + XlcNDefaultString + char* + XDefaultString() + + + XlcNEncodingName + char* + encoding name + + + XlcNLanguage + char* + language part of locale name + + + XlcNMbCurMax + int + ANSI C MB_CUR_MAX + + + XlcNStateDependentEncoding + Bool + is state-dependent encoding or not + + + XlcNTerritory + char* + territory part of locale name + + + + + + + + +Charset functions + +The XlcCharSet is an identifier which represents a subset of characters +(character set) in the locale object. + + + +typedef enum { + XlcUnknown, XlcC0, XlcGL, XlcC1, XlcGR, XlcGLGR, XlcOther +} XlcSide; + +typedef struct _XlcCharSetRec *XlcCharSet; + +typedef struct { + char *name; + XPointer value; +} XlcArg, *XlcArgList; + +typedef char* (*XlcGetCSValuesProc)(charset, args, num_args); + XlcCharSet charset; + XlcArgList args; + int num_args; + +typedef struct _XlcCharSetRec { + char *name; + XrmQuark xrm_name; + char *encoding_name; + XrmQuark xrm_encoding_name; + XlcSide side; + int char_size; + int set_size; + char *ct_sequence; + XlcGetCSValuesProc get_values; +} XlcCharSetRec; + + + +Get an XlcCharSet + + + + + XlcCharSet _XlcGetCharSet + char *name + + + + +The +_XlcGetCharSet +function gets an XlcCharSet which corresponds to the charset name +specified by "name". +_XlcGetCharSet +returns NULL, if no XlcCharSet bound to specified "name". + + + +The following character sets are pre-registered. + + + + + + + + + Name + Description + + + + + ISO8859-1:GL + 7-bit ASCII graphics (ANSI X3.4-1968), + + + + Left half of ISO 8859 sets + + + JISX0201.1976-0:GL + Left half of JIS X0201-1976 (reaffirmed 1984), + + + + 8-Bit Alphanumeric-Katakana Code + + + ISO8859-1:GR + Right half of ISO 8859-1, Latin alphabet No. 1 + + + ISO8859-2:GR + Right half of ISO 8859-2, Latin alphabet No. 2 + + + ISO8859-3:GR + Right half of ISO 8859-3, Latin alphabet No. 3 + + + ISO8859-4:GR + Right half of ISO 8859-4, Latin alphabet No. 4 + + + ISO8859-7:GR + Right half of ISO 8859-7, Latin/Greek alphabet + + + ISO8859-6:GR + Right half of ISO 8859-6, Latin/Arabic alphabet + + + ISO8859-8:GR + Right half of ISO 8859-8, Latin/Hebrew alphabet + + + ISO8859-5:GR + Right half of ISO 8859-5, Latin/Cyrillic alphabet + + + ISO8859-9:GR + Right half of ISO 8859-9, Latin alphabet No. 5 + + + JISX0201.1976-0:GR + Right half of JIS X0201-1976 (reaffirmed 1984), + + + + 8-Bit Alphanumeric-Katakana Code + + + GB2312.1980-0:GL + GB2312-1980, China (PRC) Hanzi defined as GL + + + GB2312.1980-0:GR + GB2312-1980, China (PRC) Hanzi defined as GR + + + JISX0208.1983-0:GL + JIS X0208-1983, Japanese Graphic Character Set + + + + defined as GL + + + JISX0208.1983-0:GR + JIS X0208-1983, Japanese Graphic Character Set + + + + defined as GR + + + KSC5601.1987-0:GL + KS C5601-1987, Korean Graphic Character Set + + + + defined as GL + + + KSC5601.1987-0:GR + KS C5601-1987, Korean Graphic Character Set + + + + defined as GR + + + JISX0212.1990-0:GL + JIS X0212-1990, Japanese Graphic Character Set + + + + defined as GL + + + JISX0212.1990-0:GR + JIS X0212-1990, Japanese Graphic Character Set + + + + defined as GR + + + + + + +Add an XlcCharSet + + + + + Bool _XlcAddCharSet + XlcCharSet charset + + + + +The +_XlcAddCharSet +function registers XlcCharSet specified by "charset". + + + + + +Obtain Character Set values + + + + + char * _XlcGetCSValues + XlcCharSet charset + ... + + + + +The +_XlcGetCSValues +function returns NULL if no error occurred; +otherwise, it returns the name of the first argument that could not +be obtained. The following values are defined as standard arguments. +Other values are implementation dependent. + + + + + + + + + + Name + Type + Description + + + + + XlcNName + char* + charset name + + + XlcNEncodingName + char* + XLFD CharSet Registry and Encoding + + + XlcNSide + XlcSide + charset side (GL, GR, ...) + + + XlcNCharSize + int + number of octets per character + + + XlcNSetSize + int + number of character sets + + + XlcNControlSequence + char* + control sequence of Compound Text + + + + + + + + +Converter Functions + +We provide a set of the common converter APIs, that are independent +from both of source and destination text type. + + + +typedef struct _XlcConvRec *XlcConv; + +typedef void (*XlcCloseConverterProc)(conv); + XlcConv conv; + +typedef int (*XlcConvertProc)(conv, from, from_left, to, to_left, args, num_args); + XlcConv conv; + XPointer *from; + int *from_left; + XPointer *to; + int *to_left; + XPointer *args; + int num_args; + +typedef void (*XlcResetConverterProc)(conv); + XlcConv conv; + +typedef struct _XlcConvMethodsRec { + XlcCloseConverterProc close; + XlcConvertProc convert; + XlcResetConverterProc reset; +} XlcConvMethodsRec, *XlcConvMethods; + +typedef struct _XlcConvRec { + XlcConvMethods methods; + XPointer state; +} XlcConvRec; + + + +Open a converter + + + + + XlcConv _XlcOpenConverter + XLCd from_lcd + char *from_type + XLCd to_lcd + char *to_type + + + + +_XlcOpenConverter +function opens the converter which converts a text from specified +"from_type" to specified "to_type" encoding. If the +function cannot find proper converter or cannot open a corresponding +converter, it returns NULL. Otherwise, it returns the conversion +descriptor. + + + +The following types are pre-defined. Other types are implementation +dependent. + + + + + + + + + + + Name + Type + Description + Arguments + + + + + XlcNMultiByte + char * + multibyte + - + + + XlcNWideChar + wchar_t * + wide character + - + + + XlcNCompoundText + char * + COMPOUND_TEXT + - + + + XlcNString + char * + STRING + - + + + XlcNCharSet + char * + per charset + XlcCharSet + + + XlcNChar + char * + per character + XlcCharSet + + + + + + +Close a converter + + + + + void _XlcCloseConverter + XlcConv conv + + + + +The +_XlcCloseConverter +function closes the specified converter "conv". + + + +Code conversion + + + + + int _XlcConvert + XlcConv conv + XPointer *from + int *from_left + XPointer *to + int *to_left + XPointer *args + int num_args + + + + +The +_XlcConvert +function converts a sequence of characters from one type, in the array +specified by "from", into a sequence of corresponding characters +in another type, in the array specified by "to". The types are +those specified in the +_XlcOpenConverter() +call that returned the conversion descriptor, "conv". +The arguments "from", "from_left", "to" and +"to_left" have the same specification of XPG4 iconv function. + + + +For state-dependent encodings, the conversion descriptor "conv" +is placed into its initial shift state by a call for which "from" +is a NULL pointer, or for which "from" points to a null pointer. + + + +The following 2 converters prepared by locale returns appropriate +charset (XlcCharSet) in an area pointed by args[0]. + + + + + + + + + + From + To + Description + + + + + XlcNMultiByte + XlcNCharSet + Segmentation (Decomposing) + + + XlcNWideChar + XlcNCharSet + Segmentation (Decomposing) + + + + + + +The conversion, from XlcNMultiByte/XlcNWideChar to XlcNCharSet, +extracts a segment which has same charset encoding characters. +More than one segment cannot be converted in a call. + + + +Reset a converter + + + + + void _XlcResetConverter + XlcConv conv + + + + +The +_XlcResetConverter +function reset the specified converter "conv". + + + +Register a converter + + + +typedef XlcConv (*XlcOpenConverterProc)(from_lcd, from_type, to_lcd, to_type); + XLCd from_lcd; + char *from_type; + XLCd to_lcd; + char *to_type; + + + + + Bool _XlcSetConverter + XLCd from_lcd + char *from + XLCd to_lcd + char *to + XlcOpenConverterProc converter + + + + +The XlcSetConverter function registers a converter which convert +from "from_type" to "to_type" into the converter list +(in the specified XLCd). + + + + +X Locale Database functions + +X Locale Database contains the subset of user's environment that +depends on language. The following APIs are provided for accessing +X Locale Database and other locale relative files. + + + +For more detail about X Locale Database, please refer +X Locale Database Definition document. + + + +Get a resource from database + + + + + void _XlcGetResource + XLCd lcd + char *category + char *class + char ***value + int *count + + + + +The +_XlcGetResource +function obtains a locale dependent data which is associated with the +locale of specified "lcd". +The locale data is provided by system locale or by X Locale Database +file, and what kind of data is available is implementation dependent. + + + +The specified "category" and "class" are used for +finding out the objective locale data. + + + +The returned value is returned in value argument in string list form, +and the returned count shows the number of strings in the value. + + + +The returned value is owned by locale method, and should not be modified +or freed by caller. + + + +Get a locale relative file name + + + + + char *_XlcFileName + XLCd lcd + char *category + + + + +The +_XlcFileName +functions returns a file name which is bound to the specified "lcd" +and "category", as a null-terminated string. If no file name can +be found, or there is no readable file for the found file name, +_XlcFileName +returns NULL. The returned file name should be freed by caller. + + + +The rule for searching a file name is implementation dependent. +In current implementation, +_XlcFileName +uses "{category}.dir" file as mapping table, which has pairs of +strings, a full locale name and a corresponding file name. + + + + + +Utility Functions + + +Compare Latin-1 strings + + + + + int _XlcCompareISOLatin1 + char*str1, *str2 + + + + + + int _XlcNCompareISOLatin1 + char*str1, *str2 + int len + + + + +The +_XlcCompareIsoLatin1 +function to compares two ISO-8859-1 strings. Bytes representing ASCII lower +case letters are converted to upper case before making the comparison. +The value returned is an integer less than, equal to, or greater than +zero, depending on whether "str1" is lexicographicly less than, +equal to, or greater than "str2". + + + +The +_XlcNCompareIsoLatin1 +function is identical to +_XlcCompareISOLatin1, +except that at most "len" bytes are compared. + + + +Resource Utility + + + + + int XlcNumber + ArrayType array + + + + +Similar to XtNumber. + + + + + void _XlcCopyFromArg + char *src + char *dst + int size + + + + + + void _XlcCopyToArg + char *src + char **dst + int size + + + + +Similar to +_XtCopyFromArg +and +_XtCopyToArg. + + + + + void _XlcCountVaList + va_list var + int *count_ret + + + + +Similar to +_XtCountVaList. + + + + + void _XlcVaToArgList + va_list var + int count + XlcArgList *args_ret + + + + +Similar to +_XtVaToArgList. + + + +typedef struct _XlcResource { + char *name; + XrmQuark xrm_name; + int size; + int offset; + unsigned long mask; +} XlcResource, *XlcResourceList; + + + +#define XlcCreateMask (1L<<0) +#define XlcDefaultMask (1L<<1) +#define XlcGetMask (1L<<2) +#define XlcSetMask (1L<<3) +#define XlcIgnoreMask (1L<<4) + + + + + void _XlcCompileResourceList + XlcResourceList resources + int num_resources + + + + +Similar to +_XtCompileResourceList. + + + + + char * _XlcGetValues + XPointer base + XlcResourceList resources + int num_resources + XlcArgList args + int num_args + unsignedlong mask + + + + +Similar to XtGetSubvalues. + + + + + char * _XlcSetValues + XPointer base + XlcResourceList resources + int num_resources + XlcArgList args + int num_args + unsignedlong mask + + + + +Similar to XtSetSubvalues. + + + +ANSI C Compatible Functions + + + +The following are ANSI C/MSE Compatible Functions for non-ANSI C environment. + + + + + int _Xmblen + char *str + int len + + + + +The +_Xmblen +function returns the number of characters pointed to by "str". +Only "len" bytes in "str" are used in determining the +character count returned. "Str" may point at characters from +any valid codeset in the current locale. + + + +The call +_Xmblen +is equivalent to +_Xmbtowc(_Xmbtowc((wchar_t*)NULL, str, len)) + + + + + int _Xmbtowc + wchar_t *wstr + char *str + int len + + + + +The +_Xmbtowc +function converts the character(s) pointed to by "str" +to their wide character representation(s) pointed to by "wstr". +"Len" is the number of bytes in "str" to be converted. +The return value is the number of characters converted. + + + +The call +_Xmbtowc +is equivalent to +_Xlcmbtowc((XLCd)NULL, wstr, str, len) + + + + + int _Xlcmbtowc + XLCd lcd + wchar_t *wstr + char *str + int len + + + + +The +_Xlcmbtowc +function is identical to +_Xmbtowc, +except that it requires the "lcd" argument. If "lcd" +is (XLCd) NULL, +_Xlcmbtowc, +calls +_XlcCurrentLC +to determine the current locale. + + + + + int _Xwctomb + char *str + wchar_t wc + + + + +The +_Xwctomb +function converts a single wide character pointed to by "wc" to +its multibyte representation pointed to by "str". +On success, the return value is 1. + + + +The call +_Xwctomb +is equivalent to +_Xlcwctomb((XLCd)NULL, str, wstr) + + + + + int _Xlcwctomb + XLCd lcd + char *str + wchar_t wc + + + + +The +_Xlcwctomb +function is identical to _Xwctomb, except that it requires the +"lcd" argument. If "lcd" is (XLCd) NULL, +_Xlcwctomb, +calls +_XlcCurrentLC +to determine the current locale. + + + + + int _Xmbstowcs + wchar_t *wstr + char *str + int len + + + + +The +_Xmbstowcs +function converts the NULL-terminated string pointed to by "str" +to its wide character string representation pointed to by "wstr". +"Len" is the number of characters in "str" to be converted. + + + +The call +_Xmbstowcs +is equivalent to +_Xlcmbstowcs((XLCd)NULL, wstr, str, len) + + + + + int _Xlcmbstowcs + XLCd lcd + wchar_t *wstr + char *str + int len + + + + +The +_Xlcmbstowcs +function is identical to _Xmbstowcs, except that it requires the +"lcd" argument. If "lcd" is (XLCd) NULL, +_Xlcmbstowcs, +calls +_XlcCurrentLC +to determine the current locale. + + + + + int _Xwcstombs + char *str + wchar_t *wstr + int len + + + + +The +_Xwcstombs +function converts the (wchar_t) NULL terminated wide character string +pointed to by "wstr" to the NULL terminated multibyte string +pointed to by "str". + + + +The call +_Xwcstombs +is equivalent to +_Xlcwcstombs((XLCd)NULL, str, wstr, len) + + + + + int _Xlcwcstombs + XLCd lcd + char *str + wchar_t *wstr + int len + + + + +The +_Xlcwcstombs +function is identical to _Xwcstombs, except that it requires the +"lcd" argument. If "lcd" is (XLCd) NULL, +_Xlcwcstombs, +calls +_XlcCurrentLC +to determine the current locale. + + + + + int _Xwcslen + wchar_t *wstr + + + + +The +_Xwcslen +function returns the count of wide characters in the (wchar_t) NULL +terminated wide character string pointed to by "wstr". + + + + + wchar_t * _Xwcscpy + wchar_t *wstr1 + wchar_t *wstr2 + + + + + + wchar_t * _Xwcsncpy + wchar_t *wstr1 + wchar_t *wstr2 + int len + + + + +The +_Xwcscpy +function copies the (wchar_t) NULL terminated wide character string +pointed to by "wstr2" to the object pointed at by "wstr1". +"Wstr1" is (wchar_t) NULL terminated. The return value is a +pointer to "wstr1". + + + +The +_Xwcsncpy +function is identical to +_Xwcscpy, +except that it copies "len" wide characters from the object +pointed to by "wstr2" to the object pointed to "wstr1". + + + + + int _Xwcscmp + wchar_t*wstr1, *wstr2 + + + + + + int _Xwcsncmp + wchar_t*wstr1, *wstr2 + int len + + + + +The +_Xwcscmp +function compares two (wchar_t) NULL terminated wide character strings. +The value returned is an integer less than, equal to, or greater than zero, +depending on whether "wstr1" is lexicographicly less then, equal to, +or greater than "str2". + + + +The +_Xwcsncmp +function is identical to +_XlcCompareISOLatin1, +except that at most "len" wide characters are compared. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/libX11/specs/i18n/trans/trans.xml b/libX11/specs/i18n/trans/trans.xml index c8447f934..61e2e7976 100644 --- a/libX11/specs/i18n/trans/trans.xml +++ b/libX11/specs/i18n/trans/trans.xml @@ -359,7 +359,7 @@ connection is established successfully, this function returns True. The Alternative Entry for this function is: - + Bool _XimConnect XIM im @@ -419,7 +419,7 @@ connection is closed successfully, this function returns True. The Alternative Entry for this function is: - + Bool _XimShutdown XIM im @@ -448,7 +448,7 @@ The following function is called, when Xlib needs to write data to the IM Server. - + Bool _XimWrite XIM im @@ -549,7 +549,7 @@ The following function is called when Xlib waits for response from IM server synchronously. - + Bool _XimRead XIM im @@ -788,7 +788,7 @@ transport layer. If data transfer is completed, the function returns True. The Alternative Entry for this function is: - + void _XimFlush XIM im @@ -943,7 +943,7 @@ that the data has been processed by the upper layer. The Alternative Entry for this function is: - + Bool _XimRegisterDispatcher XIM im @@ -1052,7 +1052,7 @@ Protocol packet unit or not. The Alternative Entry for this function is: - + Bool _XimCallDispatcher XIM im diff --git a/libXext/specs/dbelib.xml b/libXext/specs/dbelib.xml index c786cae81..5a969a287 100644 --- a/libXext/specs/dbelib.xml +++ b/libXext/specs/dbelib.xml @@ -1,728 +1,728 @@ - - - - - - - - - Double Buffer Extension Library - X Consortium Standard - - - - IanElliot - - - - DavideWiggins - - Hewlett-Packard Company - 1989X Consortium, Inc and Digital Equipment Corporation - 1992X Consortium, Inc and Intergraph Corporation - 1993X Consortium, Inc and Silicon Graphics, Inc. - 1994X Consortium, Inc and Hewlett-Packard Company - 1995X Consortium, Inc and Hewlett-Packard Company - Version 1.0 - X Consortium - X Version 11, Release 7 - - - -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. - - - - - - - -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. - - - - - -Goals - - -This extension should enable clients to: - - - - -Allocate and deallocate double-buffering for a window. - - - - -Draw to and read from the front and back buffers associated with a window. - - - - -Swap the front and back buffers associated with a window. - - - - -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). - - - - -Request that the front and back buffers associated with multiple -double-buffered windows be swapped simultaneously. - - - - - -In addition, the extension should: - - - - -Allow multiple clients to use double-buffering on the same window. - - - - -Support a range of implementation methods that can capitalize on -existing hardware features. - - - - -Add no new event types. - - - - -Be reasonably easy to integrate with a variety of direct graphics -hardware access (DGHA) architectures. - - - - - - - -Concepts - -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. - - -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. - - -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. -particular, here are some important characteristics: - - - - -Only one buffer per window can be visible at a time (the front buffer). - - - - -Both buffers associated with a window have the same visual type, depth, -width, height, and shape as the window. - - - - -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. - - - - -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. - - - - -It is an error (Window) to pass a BACKBUFFER in a core request that -expects a Window. - - - - -A BACKBUFFER will never be sent by core X in a reply, event, or -error where a Window is specified. - - - - -If core X11 backing-store and save-under applies to a double-buffered -window, it applies to both buffers equally. - - - - -If the core ClearArea request is executed on a double-buffered window, -the same area in both the front and back buffers is cleared. - - - - - -The effect of passing a window to a request that accepts a -DRAWABLE is -unchanged by this extension. The window and front buffer are synonomous -with each other. This includes obeying the GetImage -semantics and the -subwindow-mode semantics if a core graphics context is involved. Regardless -of whether the window was explicitly passed in a -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-naive screen dump clients will always get the front buffer. -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 -ClipByChildren. 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 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 DRAWABLE type called -BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for -example, GraphicsExpose) are generated in response to -a request, the -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. - - - -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 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 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 -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, -Expose 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. - - -If the Shape extension -ShapeRectangles, -ShapeMask, -ShapeCombine, or -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 = newshape − oldshape - - - -It is tiled with the window background in both buffers, and -Expose -events are generated for D. - - - - - -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: -DBEBeginIdiom and 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: - - - - - -DBEBeginIdiom request. - - - - -DBESwapBuffers request with XIDs for two windows, each of which uses -a swap action of Untouched. - - - - -Core X PolyFillRectangle request to the back buffer of one window. - - - - -Core X PolyFillRectangle request to the back buffer of the other -window. - - - - -DBEEndIdiom request. - - - - - -The DBEBeginIdiom and 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 DBESwapBuffers request. -For example, if a swap action of Copied is desired, -but only some of the planes should be copied, a core X -CopyArea request may be used instead of -DBESwapBuffers. If -DBESwapBuffers is included in an idiom, it should -immediately follow the -DBEBeginIdiom request. Also, when the -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 Untouched, and if a -PolyFillRectangle using a client clip -rectangle is done to the window’s back buffer after the -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 -DBEBeginIdiom request, the idiom -requests, and DBEEndIdiom request. Usage of these -functions will ensure best possible performance across a wide -variety of implementations. - - - - - - -C Language Binding - -All identifier The header for this extension is <X11/extensions/Xdbe.h>. -names provided by this header begin with Xdbe. - - - -Types - - -The type XdbeBackBuffer is a Drawable. - - - -The type XdbeSwapAction can be one of the constants -XdbeUndefined, -XdbeBackground, -XdbeUntouched, or -XdbeCopied. - - - - - -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 -Status will return nonzero for success and -zero for failure. - - - - - Status XdbeQueryExtension - Display *dpy - int *major_version_return - int *minor_version_return - - - - -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. - - - - - XdbeScreenVisualInfo *XdbeGetVisualInfo - Display *dpy - Drawable *screen_specifiers - int *num_screens - - - - - -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 -XdbeScreenVisualInfo -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. - - - - -The XdbeScreenVisualInfo structure has the following fields: - - -int count number of items in visinfo -XdbeVisualInfo* visinfo list of visuals and depths for this screen - - - -The XdbeVisualInfo structure has the following fields: - - - -VisualID visual one visual ID that supports double-buffering -int depth depth of visual in bits -int perflevel performance level of visual - - - - - - void XdbeFreeVisualInfo XdbeGetVisualInfo - XdbeScreenVisualInfo *visual_info - - - - -XdbeFreeVisualInfo frees the list of -XdbeScreenVisualInfo returned by -XdbeGetVisualInfo. - - - - - - XdbeBackBuffer XdbeAllocateBackBufferName - Display *dpy - Window *window - XdbeSwapAction swap_action - - - - - -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 XdbeSwapBuffers. The actual swap_action -used in calls to 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. - - - - - Status XdbeDeallocateBackBufferName - Display *dpy - XdbeBackBuffer buffer - - - - -XdbeDeallocateBackBufferName frees the specified -drawable ID, buffer, that was obtained via -XdbeAllocateBackBufferName. The buffer must be a valid -name for the back buffer of a window, or an -XdbeBadBuffer error results. - - - - - Status XdbeSwapBuffers - Display *dpy - XdbeSwapInfo *swap_info - int num_windows - - - - -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 XdbeSwapInfo structure has the following fields: - - - -Window swap_window window for which to swap buffers -XdbeSwapAction swap_action swap action to use for this swap window - - - - - Status XdbeBeginIdiom - Display *dpy - - - - -XdbeBeginIdiom marks the beginning of an idiom -sequence. See - - -for a complete discussion of idioms. - - - - - Status XdbeEndIdiom - Display *dpy - - - - -XdbeEndIdiom marks the end of an idiom sequence. - - - - - XdbeBackBufferAttributes *XdbeGetBackBufferAttributes - Display *dpy - XdbeBackBuffer buffer - - - - -XdbeGetBackBufferAttributes returns the attributes associated with -the specified buffer. - - -The XdbeBackBufferAttributes structure has the following fields: - - - -Window window window that buffer belongs to - - - -If buffer is not a valid XdbeBackBuffer, window is -set to None. - - -The returned XdbeBackBufferAttributes structure -can be freed with the Xlib function XFree. - - - - -Errors - -The XdbeBufferError structure has the following fields: - - -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 + XdbeBadBuffer -unsigned char request code Major op-code of failed request -unsigned char minor code Minor op-code of failed request - - - - - -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. - - - - -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." - - - + + + + + + + + + Double Buffer Extension Library + X Consortium Standard + + + + IanElliot + + + + DavideWiggins + + Hewlett-Packard Company + 1989X Consortium, Inc and Digital Equipment Corporation + 1992X Consortium, Inc and Intergraph Corporation + 1993X Consortium, Inc and Silicon Graphics, Inc. + 1994X Consortium, Inc and Hewlett-Packard Company + 1995X Consortium, Inc and Hewlett-Packard Company + Version 1.0 + X Consortium + X Version 11, Release 7 + + + +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. + + + + + + + +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. + + + + + +Goals + + +This extension should enable clients to: + + + + +Allocate and deallocate double-buffering for a window. + + + + +Draw to and read from the front and back buffers associated with a window. + + + + +Swap the front and back buffers associated with a window. + + + + +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). + + + + +Request that the front and back buffers associated with multiple +double-buffered windows be swapped simultaneously. + + + + + +In addition, the extension should: + + + + +Allow multiple clients to use double-buffering on the same window. + + + + +Support a range of implementation methods that can capitalize on +existing hardware features. + + + + +Add no new event types. + + + + +Be reasonably easy to integrate with a variety of direct graphics +hardware access (DGHA) architectures. + + + + + + + +Concepts + +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. + + +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. + + +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. +particular, here are some important characteristics: + + + + +Only one buffer per window can be visible at a time (the front buffer). + + + + +Both buffers associated with a window have the same visual type, depth, +width, height, and shape as the window. + + + + +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. + + + + +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. + + + + +It is an error (Window) to pass a BACKBUFFER in a core request that +expects a Window. + + + + +A BACKBUFFER will never be sent by core X in a reply, event, or +error where a Window is specified. + + + + +If core X11 backing-store and save-under applies to a double-buffered +window, it applies to both buffers equally. + + + + +If the core ClearArea request is executed on a double-buffered window, +the same area in both the front and back buffers is cleared. + + + + + +The effect of passing a window to a request that accepts a +DRAWABLE is +unchanged by this extension. The window and front buffer are synonomous +with each other. This includes obeying the GetImage +semantics and the +subwindow-mode semantics if a core graphics context is involved. Regardless +of whether the window was explicitly passed in a +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-naive screen dump clients will always get the front buffer. +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 +ClipByChildren. 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 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 DRAWABLE type called +BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for +example, GraphicsExpose) are generated in response to +a request, the +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. + + + +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 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 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 +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, +Expose 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. + + +If the Shape extension +ShapeRectangles, +ShapeMask, +ShapeCombine, or +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 = newshape − oldshape + + + +It is tiled with the window background in both buffers, and +Expose +events are generated for D. + + + + + +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: +DBEBeginIdiom and 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: + + + + + +DBEBeginIdiom request. + + + + +DBESwapBuffers request with XIDs for two windows, each of which uses +a swap action of Untouched. + + + + +Core X PolyFillRectangle request to the back buffer of one window. + + + + +Core X PolyFillRectangle request to the back buffer of the other +window. + + + + +DBEEndIdiom request. + + + + + +The DBEBeginIdiom and 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 DBESwapBuffers request. +For example, if a swap action of Copied is desired, +but only some of the planes should be copied, a core X +CopyArea request may be used instead of +DBESwapBuffers. If +DBESwapBuffers is included in an idiom, it should +immediately follow the +DBEBeginIdiom request. Also, when the +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 Untouched, and if a +PolyFillRectangle using a client clip +rectangle is done to the window’s back buffer after the +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 +DBEBeginIdiom request, the idiom +requests, and DBEEndIdiom request. Usage of these +functions will ensure best possible performance across a wide +variety of implementations. + + + + + + +C Language Binding + +All identifier The header for this extension is <X11/extensions/Xdbe.h>. +names provided by this header begin with Xdbe. + + + +Types + + +The type XdbeBackBuffer is a Drawable. + + + +The type XdbeSwapAction can be one of the constants +XdbeUndefined, +XdbeBackground, +XdbeUntouched, or +XdbeCopied. + + + + + +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 +Status will return nonzero for success and +zero for failure. + + + + + Status XdbeQueryExtension + Display *dpy + int *major_version_return + int *minor_version_return + + + + +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. + + + + + XdbeScreenVisualInfo *XdbeGetVisualInfo + Display *dpy + Drawable *screen_specifiers + int *num_screens + + + + + +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 +XdbeScreenVisualInfo +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. + + + + +The XdbeScreenVisualInfo structure has the following fields: + + +int count number of items in visinfo +XdbeVisualInfo* visinfo list of visuals and depths for this screen + + + +The XdbeVisualInfo structure has the following fields: + + + +VisualID visual one visual ID that supports double-buffering +int depth depth of visual in bits +int perflevel performance level of visual + + + + + + void XdbeFreeVisualInfo XdbeGetVisualInfo + XdbeScreenVisualInfo *visual_info + + + + +XdbeFreeVisualInfo frees the list of +XdbeScreenVisualInfo returned by +XdbeGetVisualInfo. + + + + + + XdbeBackBuffer XdbeAllocateBackBufferName + Display *dpy + Window *window + XdbeSwapAction swap_action + + + + + +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 XdbeSwapBuffers. The actual swap_action +used in calls to 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. + + + + + Status XdbeDeallocateBackBufferName + Display *dpy + XdbeBackBuffer buffer + + + + +XdbeDeallocateBackBufferName frees the specified +drawable ID, buffer, that was obtained via +XdbeAllocateBackBufferName. The buffer must be a valid +name for the back buffer of a window, or an +XdbeBadBuffer error results. + + + + + Status XdbeSwapBuffers + Display *dpy + XdbeSwapInfo *swap_info + int num_windows + + + + +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 XdbeSwapInfo structure has the following fields: + + + +Window swap_window window for which to swap buffers +XdbeSwapAction swap_action swap action to use for this swap window + + + + + Status XdbeBeginIdiom + Display *dpy + + + + +XdbeBeginIdiom marks the beginning of an idiom +sequence. See + + +for a complete discussion of idioms. + + + + + Status XdbeEndIdiom + Display *dpy + + + + +XdbeEndIdiom marks the end of an idiom sequence. + + + + + XdbeBackBufferAttributes *XdbeGetBackBufferAttributes + Display *dpy + XdbeBackBuffer buffer + + + + +XdbeGetBackBufferAttributes returns the attributes associated with +the specified buffer. + + +The XdbeBackBufferAttributes structure has the following fields: + + + +Window window window that buffer belongs to + + + +If buffer is not a valid XdbeBackBuffer, window is +set to None. + + +The returned XdbeBackBufferAttributes structure +can be freed with the Xlib function XFree. + + + + +Errors + +The XdbeBufferError structure has the following fields: + + +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 + XdbeBadBuffer +unsigned char request code Major op-code of failed request +unsigned char minor code Minor op-code of failed request + + + + + +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. + + + + +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." + + + diff --git a/libXext/specs/dpmslib.xml b/libXext/specs/dpmslib.xml index 809f3b77b..1fe81d2af 100644 --- a/libXext/specs/dpmslib.xml +++ b/libXext/specs/dpmslib.xml @@ -1,419 +1,419 @@ - - - - - - - - X Display Power Management Signaling (DPMS) Extension - X Consortium Standard - X Version 11, Release 6.8 - - - RobLembree - - - Digital Equipment Corporation - 1996X Consortium - Version 1.0 - X Consortium - X Version 11, Release 6.8 - - - -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. - - - -X Window System is a trademark of The Open Group. - - - - - - -Overview - -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. - - - -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. - - - -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. - - - -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: - - - -DPMS Extension Power Levels - 0 DPMSModeOn In use - 1 DPMSModeStandby Blanked, low power - 2 DPMSModeSuspend Blanked, lower power - 3 DPMSModeOff Shut off, awaiting activity - - - - - -DPMS Functions - - - - - Bool DPMSQueryExtention - Display *display - int event_base - int error_base - - - - - - *display - Specifies the connection to the X server. - - - event_base - Specifies the return location for the assigned base event - - - error_base - Specifies the return location for the assigned base error - - - - -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 event_base and -error_base 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 -event_base and -error_base are undefined. - - - - - Status DPMSGetVersion - Display *display - int *major_version - int *minor_version - - - - - - display - Specifies the connection to the X server. - - - major_version - Specifies the return location for the extension major version. - - - minor_version - Specifies the return location for the extension minor version. - - - - - -The DPMSGetVersion function returns the version of the DPMS extension -implemented by the X server. The version is returned in -major_version and -minor_version. -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. - - - - - Bool DPMSCapable - Display *display - - - - - - display - Specifies the connection to the X server. - - - - - -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. - - - - - Status DPMSSetTimeouts - Display *display - CARD16 standby - CARD16 suspend - CARD16 off - - - - - - display - Specifies the connection to the X server. - - - standby - Specifies the new standby timeout in seconds. - - - suspend - Specifies the new suspend timeout in seconds. - - - off - Specifies the new off timeout in seconds. - - - - -The DPMSSetTimeouts function permits applications to set the timeout values -used by the X server for DPMS timings. - - - -The value standby 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. - - - -The value suspend 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. - - - -The value off 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. - - - -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. - - - - - Status DPMSGetTimeouts - Display *display - CARD16 *standby - CARD16 *suspend - CARD16 *off - - - - - - display - Specifies the connection to the X server. - - - standby - Specifies the new standby timeout in seconds. - - - suspend - Specifies the new suspend timeout in seconds. - - - off - Specifies the new off timeout in seconds. - - - - -The DPMSGetTimeouts function retrieves the timeout values used by the X -server for DPMS timings. - - - -The value standby 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. - - - -The value suspend 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. - - - -The value off 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. - - - - - Status DPMSEnable - Display *display - - - - - - display - Specifies the connection to the X server. - - - - -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. - - - - - Status DPMSDisable - Display *display - - - - - - display - Specifies the connection to the X server. - - - - -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. - - - - - Status DPMSForceLevel - Display *display - CARD16 level - - - - - - display - Specifies the connection to the X server. - - - level - Specifies the level to force power to. - - - - -The DPMSForceLevel function forces a DPMS capable display into the -specified power level. The level 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. - - -Status DPMSInfo(display, power_level, state) - - - - Status DPMSInfo - Display *display - CARD16 power_level - BOOL *state - - - - - - display - Specifies the connection to the X server. - - - power_level - Specifies the current power level. - - - state - Specifies the current DPMS state. - - - - -The DPMSInfo function returns information about the current DPMS state. -The state return parameter indicates whether -or not DPMS is enabled (TRUE) or disabled (FALSE). The -power_level return parameter indicates the -current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, -or DPMSModeOff.) - - - - + + + + + + + + X Display Power Management Signaling (DPMS) Extension + X Consortium Standard + X Version 11, Release 6.8 + + + RobLembree + + + Digital Equipment Corporation + 1996X Consortium + Version 1.0 + X Consortium + X Version 11, Release 6.8 + + + +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. + + + +X Window System is a trademark of The Open Group. + + + + + + +Overview + +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. + + + +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. + + + +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. + + + +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: + + + +DPMS Extension Power Levels + 0 DPMSModeOn In use + 1 DPMSModeStandby Blanked, low power + 2 DPMSModeSuspend Blanked, lower power + 3 DPMSModeOff Shut off, awaiting activity + + + + + +DPMS Functions + + + + + Bool DPMSQueryExtention + Display *display + int event_base + int error_base + + + + + + *display + Specifies the connection to the X server. + + + event_base + Specifies the return location for the assigned base event + + + error_base + Specifies the return location for the assigned base error + + + + +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 event_base and +error_base 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 +event_base and +error_base are undefined. + + + + + Status DPMSGetVersion + Display *display + int *major_version + int *minor_version + + + + + + display + Specifies the connection to the X server. + + + major_version + Specifies the return location for the extension major version. + + + minor_version + Specifies the return location for the extension minor version. + + + + + +The DPMSGetVersion function returns the version of the DPMS extension +implemented by the X server. The version is returned in +major_version and +minor_version. +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. + + + + + Bool DPMSCapable + Display *display + + + + + + display + Specifies the connection to the X server. + + + + + +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. + + + + + Status DPMSSetTimeouts + Display *display + CARD16 standby + CARD16 suspend + CARD16 off + + + + + + display + Specifies the connection to the X server. + + + standby + Specifies the new standby timeout in seconds. + + + suspend + Specifies the new suspend timeout in seconds. + + + off + Specifies the new off timeout in seconds. + + + + +The DPMSSetTimeouts function permits applications to set the timeout values +used by the X server for DPMS timings. + + + +The value standby 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. + + + +The value suspend 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. + + + +The value off 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. + + + +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. + + + + + Status DPMSGetTimeouts + Display *display + CARD16 *standby + CARD16 *suspend + CARD16 *off + + + + + + display + Specifies the connection to the X server. + + + standby + Specifies the new standby timeout in seconds. + + + suspend + Specifies the new suspend timeout in seconds. + + + off + Specifies the new off timeout in seconds. + + + + +The DPMSGetTimeouts function retrieves the timeout values used by the X +server for DPMS timings. + + + +The value standby 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. + + + +The value suspend 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. + + + +The value off 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. + + + + + Status DPMSEnable + Display *display + + + + + + display + Specifies the connection to the X server. + + + + +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. + + + + + Status DPMSDisable + Display *display + + + + + + display + Specifies the connection to the X server. + + + + +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. + + + + + Status DPMSForceLevel + Display *display + CARD16 level + + + + + + display + Specifies the connection to the X server. + + + level + Specifies the level to force power to. + + + + +The DPMSForceLevel function forces a DPMS capable display into the +specified power level. The level 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. + + +Status DPMSInfo(display, power_level, state) + + + + Status DPMSInfo + Display *display + CARD16 power_level + BOOL *state + + + + + + display + Specifies the connection to the X server. + + + power_level + Specifies the current power level. + + + state + Specifies the current DPMS state. + + + + +The DPMSInfo function returns information about the current DPMS state. +The state return parameter indicates whether +or not DPMS is enabled (TRUE) or disabled (FALSE). The +power_level return parameter indicates the +current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, +or DPMSModeOff.) + + + + diff --git a/libXext/specs/shapelib.xml b/libXext/specs/shapelib.xml index 1d89cf1e1..a357da40b 100644 --- a/libXext/specs/shapelib.xml +++ b/libXext/specs/shapelib.xml @@ -1,577 +1,577 @@ - - - - - - - - X Nonrectangular Window Shape Extension Library - X Consortium Standard - X Version 11, Release 6.4 - - - KeithPackard - - - MIT X Consortium - 1989X Consortium - Version 1.0 - MIT X Consortium - X Version 11, Release 6.4 - - - - -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. - - - - - -Overview - -This extension provides arbitrary window and border shapes within -the X11 protocol. - - - -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. - - - -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. - - - - -Description - - -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. - - - -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 width by -height and border width -bwidth, the default bounding and clip -regions are the rectangles (relative to the window origin): - - - -bounding.x = -bwidth -bounding.y = -bwidth -bounding.width = width + 2 * bwidth -bounding.height = height + 2 * bwidth - -clip.x = 0 -clip.y = 0 -clip.width = width -clip.height = height - - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - -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. - - - -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. - - - - -C Language Binding - - -The C functions provide direct access to the protocol and add no additional -semantics. - - -The include file for this extension is -<X11/extensions/shape.h>. -The defined shape kinds are -ShapeBounding -and -ShapeClip -The defined region operations are -ShapeSet -ShapeUnion -ShapeIntersect -ShapeSubtract -and -ShapeInvert. - - - -Bool XShapeQueryExtension -Display *display -int *event_base -int *error_base - - - - -XShapeQueryExtension -returns -True -if the specified display supports the SHAPE extension else -False -If the extension is supported, *event_base is set to the event number for -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). - - - - -Status XShapeQueryVersion -Display *display -int *major_version -int *minor_version - - - - -If the extension is supported, -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. - - - - -XShapeCombineRegion -Display *display -Window dest -int dest_kind -int x_off -int y_off -int region -int op -REGION *region - - - - -XShapeCombineRegion -converts the specified region into a list of rectangles and calls -XShapeCombineRectangles - - - - -XShapeCombineRectangles -Display *display -Window dest -int dest_kind -int x_off -int y_off -XRectangle *rectangles -int n_rects -int op -int ordering - - - - -If the extension is supported, -XShapeCombineRectangles -performs a -ShapeRectangles -operation; otherwise, the request is ignored. - - - - -XShapeCombineMask -Display *display -int dest -int dest_kind -int x_off -int y_off -Pixmap src -int op - - - - -If the extension is supported, -XShapeCombineMask -performs a -ShapeMask -operation; otherwise, the request is ignored. - - - - -XShapeCombineShape -Display *display -Window dest -int dest_kind -int x_off -int y_off -Window src -int src_kind -int op - - - - -If the extension is supported, -XShapeCombineShape -performs a -ShapeCombine -operation; otherwise, the request is ignored. - - - - -XShapeOffsetShape -display -dest -dest_kind -x_off -y_off - - - - -If the extension is supported, -XShapeOffsetShape -performs a -ShapeOffset -operation; otherwise, the request is ignored. - - - - -Status XShapeQueryExtents -Display *display -Window window -Bool *bounding_shaped -int *x_bounding -int *y_bounding -unsigned int *w_bounding -unsigned int *h_bounding -Bool *clip_shaped -int *x_clip -int *y_clip -unsigned int *w_clip -unsigned int *h_clip - - - - -If the extension is supported, -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. - - - -If the extension is supported, a nonzero value is returned; otherwise, -zero is returned. - - - - -XShapeSelectInput -Display *display -Window window -unsigned long mask - - - - -To make this extension more compatible with other interfaces, although -only one event type can be selected via the extension, -XShapeSelectInput -provides a general mechanism similar to the standard Xlib binding for -window events. A mask value has been defined, -ShapeNotifyMask -that is the only valid bit in mask that may be specified. -The structure for this event is defined as follows: - - - -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; - - - - -unsigned long XShapeInputSelected -Display *display -Window window - - - - -XShapeInputSelected -returns the current input mask for extension events on the specified -window; the value returned if -ShapeNotify -is selected for is -ShapeNotifyMask -otherwise, it returns zero. -If the extension is not supported, it returns zero. - - - - -XRectangle *XShapeGetRectangles -Display *display -Window window -int kind -int *count -int *ordering - - - - -If the extension is not supported, -XShapeGetRectangles -returns NULL. Otherwise, it returns a list of rectangles that describe the -region specified by kind. - - - - - - - bounding region - The area of the parent window that this window will occupy. -This area is divided into two parts: the border and the interior. - - - - - clip region - 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. - - - - default bounding region - The rectangular area, as described by the core protocol -window size, that covers the interior of the window and its border. - - - - - default clip region - The rectangular area, as described by the core protocol -window size, that covers the interior of the window and excludes the border. - - - - - client bounding region - The region associated with a window that is directly -modified via this extension when specified by -ShapeBounding -This region is used in conjunction with the default bounding region -to produce the effective bounding region. - - - - client clip region - The region associated with a window that is directly -modified via this extension when specified by -ShapeClip -This region is used in conjunction with the default clip region -and the client bounding region to produce the effective clip region. - - - - - effective bounding region - 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. - - - - - effective clip region - 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. - - - - + + + + + + + + X Nonrectangular Window Shape Extension Library + X Consortium Standard + X Version 11, Release 6.4 + + + KeithPackard + + + MIT X Consortium + 1989X Consortium + Version 1.0 + MIT X Consortium + X Version 11, Release 6.4 + + + + +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. + + + + + +Overview + +This extension provides arbitrary window and border shapes within +the X11 protocol. + + + +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. + + + +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. + + + + +Description + + +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. + + + +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 width by +height and border width +bwidth, the default bounding and clip +regions are the rectangles (relative to the window origin): + + + +bounding.x = -bwidth +bounding.y = -bwidth +bounding.width = width + 2 * bwidth +bounding.height = height + 2 * bwidth + +clip.x = 0 +clip.y = 0 +clip.width = width +clip.height = height + + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + +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. + + + +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. + + + + +C Language Binding + + +The C functions provide direct access to the protocol and add no additional +semantics. + + +The include file for this extension is +<X11/extensions/shape.h>. +The defined shape kinds are +ShapeBounding +and +ShapeClip +The defined region operations are +ShapeSet +ShapeUnion +ShapeIntersect +ShapeSubtract +and +ShapeInvert. + + + +Bool XShapeQueryExtension +Display *display +int *event_base +int *error_base + + + + +XShapeQueryExtension +returns +True +if the specified display supports the SHAPE extension else +False +If the extension is supported, *event_base is set to the event number for +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). + + + + +Status XShapeQueryVersion +Display *display +int *major_version +int *minor_version + + + + +If the extension is supported, +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. + + + + +XShapeCombineRegion +Display *display +Window dest +int dest_kind +int x_off +int y_off +int region +int op +REGION *region + + + + +XShapeCombineRegion +converts the specified region into a list of rectangles and calls +XShapeCombineRectangles + + + + +XShapeCombineRectangles +Display *display +Window dest +int dest_kind +int x_off +int y_off +XRectangle *rectangles +int n_rects +int op +int ordering + + + + +If the extension is supported, +XShapeCombineRectangles +performs a +ShapeRectangles +operation; otherwise, the request is ignored. + + + + +XShapeCombineMask +Display *display +int dest +int dest_kind +int x_off +int y_off +Pixmap src +int op + + + + +If the extension is supported, +XShapeCombineMask +performs a +ShapeMask +operation; otherwise, the request is ignored. + + + + +XShapeCombineShape +Display *display +Window dest +int dest_kind +int x_off +int y_off +Window src +int src_kind +int op + + + + +If the extension is supported, +XShapeCombineShape +performs a +ShapeCombine +operation; otherwise, the request is ignored. + + + + +XShapeOffsetShape +display +dest +dest_kind +x_off +y_off + + + + +If the extension is supported, +XShapeOffsetShape +performs a +ShapeOffset +operation; otherwise, the request is ignored. + + + + +Status XShapeQueryExtents +Display *display +Window window +Bool *bounding_shaped +int *x_bounding +int *y_bounding +unsigned int *w_bounding +unsigned int *h_bounding +Bool *clip_shaped +int *x_clip +int *y_clip +unsigned int *w_clip +unsigned int *h_clip + + + + +If the extension is supported, +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. + + + +If the extension is supported, a nonzero value is returned; otherwise, +zero is returned. + + + + +XShapeSelectInput +Display *display +Window window +unsigned long mask + + + + +To make this extension more compatible with other interfaces, although +only one event type can be selected via the extension, +XShapeSelectInput +provides a general mechanism similar to the standard Xlib binding for +window events. A mask value has been defined, +ShapeNotifyMask +that is the only valid bit in mask that may be specified. +The structure for this event is defined as follows: + + + +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; + + + + +unsigned long XShapeInputSelected +Display *display +Window window + + + + +XShapeInputSelected +returns the current input mask for extension events on the specified +window; the value returned if +ShapeNotify +is selected for is +ShapeNotifyMask +otherwise, it returns zero. +If the extension is not supported, it returns zero. + + + + +XRectangle *XShapeGetRectangles +Display *display +Window window +int kind +int *count +int *ordering + + + + +If the extension is not supported, +XShapeGetRectangles +returns NULL. Otherwise, it returns a list of rectangles that describe the +region specified by kind. + + + + + + + bounding region + The area of the parent window that this window will occupy. +This area is divided into two parts: the border and the interior. + + + + + clip region + 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. + + + + default bounding region + The rectangular area, as described by the core protocol +window size, that covers the interior of the window and its border. + + + + + default clip region + The rectangular area, as described by the core protocol +window size, that covers the interior of the window and excludes the border. + + + + + client bounding region + The region associated with a window that is directly +modified via this extension when specified by +ShapeBounding +This region is used in conjunction with the default bounding region +to produce the effective bounding region. + + + + client clip region + The region associated with a window that is directly +modified via this extension when specified by +ShapeClip +This region is used in conjunction with the default clip region +and the client bounding region to produce the effective clip region. + + + + + effective bounding region + 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. + + + + + effective clip region + 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. + + + + diff --git a/libXext/specs/synclib.xml b/libXext/specs/synclib.xml index 3edeaaaa7..36c716297 100644 --- a/libXext/specs/synclib.xml +++ b/libXext/specs/synclib.xml @@ -1,813 +1,813 @@ - - - - - - - - - X Synchronization Extension Library - X Consortium Standard - X Version 11, Release 6.4 - - - TimGlauert - Olivetti Research/MultiWorks - - - Dave - Carver - Digital Equipment Corporation, MIT/Project Athena - - - Jim - Gettys - Digital Equipment Corporation, Cambridge Research Laboratory - - - David - Wiggins - X Consortium, Inc. - - - Version 3.0 - X Consortium - X Version 11, Release 6.4 - - - -Copyright 1991 by Olivetti Research Limited, Cambridge England and Digital Equipment Corporation, Maynard, Massachusetts - - - -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 © 1991 X Consortium, Inc. - - - -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. - - - - - - -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. - - - -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 Counter and -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 Await request that waits until -one of a set of synchronization conditions, called TRIGGERs, becomes TRUE. - - -The CreateCounter request allows a client to create -a Counter that can be changed by explicit -SetCounter and ChangeCounter -requests. These can be used to implement synchronization between -different clients. - - -There are some counters, called 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 Alarm mechanism that allows clients to receive an -event on a regular basis when a particular counter is changed. - - - - - -C Language Binding - - -The C routines provide direct access to the protocol and add no additional -semantics. - - -The include file for this extension is <X11/extensions/sync.h>. -Most of the names in the language binding are derived from the protocol -names by prepending XSync to the protocol name and changing the -capitalization. - - - -C Functions - - -Most of the following functions generate SYNC protocol requests. - - - - - Status XSyncQueryExtension - Display *dpy - int *event_base_return - int *error_base_return - - - - -If dpy supports the SYNC extension, -XSyncQueryExtension returns 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 False. - - - - - Status XSyncInitialize - Display *dpy - int *major_version_return - int *minor_version_return - - - - -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 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 False. -The only XSync function that may be called before this function is -XSyncQueryExtension. If a client violates this rule, the effects of all XSync -calls that it makes are undefined. - - - - - XSyncSystemCounter *XSyncListSystemCounters - Display *dpy - int *n_counters_return - - - - -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 -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. - - - -XSyncSystemCounter has the following fields: - - - -char * name; /* null-terminated name of system counter */ -XSyncCounter counter; /* counter id of this system counter */ -XSyncValue resolution; /* resolution of this system counter */ - - - - - void XSyncFreeSystemCounterList - XSyncSystemCounter *list - - - - -XSyncFreeSystemCounterList frees the memory -associated with the system counter list returned by -XSyncListSystemCounters. - - - - - XSyncCounter XSyncCreateCounter - Display *dpy - XSyncValue initial_value - - - - -XSyncCreateCounter creates a counter on the dpy -with the given initial value and returns the counter ID. It returns -None if dpy does not support the SYNC extension. - - - - - Status XSyncSetCounter - Display *dpy - XSyncCounter counter - XSyncValue value - - - - - -XSyncSetCounter sets counter to value. It returns -False if dpy does not -support the SYNC extension; otherwise, it returns True. - - - - - Status XSyncChangeCounter - Display *dpy - XSyncCounter counter - XSyncValue value - - - - -XSyncChangeCounter adds value to counter. It returns -False if dpy does not support the SYNC extension; -otherwise, it returns -True. - - - - Status XSyncDestroyCounter - Display *dpy - XSyncCounter counter - - - - -XSyncDestroyCounter destroys counter. It returns -False if dpy does not support the SYNC extension; -otherwise, it returns True. - - - - - Status XSyncQueryCounter - Display *dpy - XSyncCounter counter - XSyncValue *value_return - - - - -XSyncQueryCounter sets *value_return to the current -value of counter. It returns False if there was an -error during communication with the server or if dpy does not support the -SYNC extension; otherwise, it returns True. - - - - - Status XSyncAwait - Display *dpy - XSyncWaitCondition *wait_list - int n_conditions - - - - -XSyncAwait awaits on the conditions in wait_list. -The n_conditions is the number of wait conditions in wait_list. It -returns False if dpy does not support the SYNC -extension; otherwise, it returns True. The await is -processed asynchronously by the server; this function always returns -immediately after issuing the request. - - -XSyncWaitCondition has the following fields: - - - -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 */ - - - -XSyncValueType can be either -XSyncAbsolute or XSyncRelative. - - - -XSyncTestType can be one of -XSyncPositiveTransition, -XSyncNegativeTransition, -XSyncPositiveComparison, or -XSyncNegativeComparison. - - - - - XSyncAlarm XSyncCreateAlarm - Display *dpy - unsigned long values_mask - XSyncAlarmAttributes *values` - - - - -XSyncCreateAlarm creates an alarm and returns the -alarm ID. It returns None if the display does not support the SYNC -extension. The values_mask and values specify the alarm attributes. - - - -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 CreateAlarm for the -defaults. - - - -type field name attribute_mask -XSyncCounter trigger.counter; XSyncCACounter -XSyncValueType trigger.value_type; XSyncCAValueType -XSyncValue trigger.wait_value; XSyncCAValue -XSyncTestType trigger.test_type; XSyncCATestType -XSyncValue delta; XSyncCADelta -Bool events; XSyncCAEvents -XSyncAlarmState state; client cannot set this - - - - - Status XSyncDestroyAlarm - Display *dpy - XSyncAlarm alarm - - - - -XSyncDestroyAlarm destroys alarm. It returns -False if dpy does not support -the SYNC extension; otherwise, it returns True. - - - - - Status XSyncQueryAlarm - Display *dpy - XSyncAlarm alarm - XSyncAlarmAttributes *values_return - - - - - -XSyncQueryAlarm sets *values_return to the alarm’s -attributes. It returns False if there was an error -during communication with the server or if dpy does not support the -SYNC extension; otherwise, it returns True. - - - - - Status XSyncChangeAlarm - Display *dpy - XSyncAlarm alarm - unsigned long values_mask - XSyncAlarmAttributes *values - - - - -XSyncChangeAlarm changes alarm’s attributes. The -attributes to change are specified as in -XSyncCreateAlarm. It returns -False if dpy does not support -the SYNC extension; otherwise, it returns True. - - - - - Status XSyncSetPriority - Display *dpy - XID client_resource_id - int priority - - - - -XSyncSetPriority sets the priority of the client -owning client_resource_id to priority. If client_resource_id is None, it -sets the caller’s priority. It returns -False if dpy does not support the SYNC extension; -otherwise, it returns True. - - - - - Status XSyncGetPriority - Display *dpy - XID client_resource_id - int *return_priority - - - - -XSyncGetPriority sets *return_priority to the -priority of the client owning client_resource_id. If client_resource_id -is None, it sets *return_priority to the caller’s priority. It returns -False if there was an error during communication -with the server or if dpy does not support the SYNC extension; otherwise, it -returns True. - - - - - -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. - - - - - void XSyncIntToValue - XSyncValue *pv - int i - - - - -Converts i to an XSyncValue and stores it in *pv. -Performs sign extension (*pv will have the same sign as i.) - - - - - void XSyncIntsToValue - XSyncValue *pv - unsigned int low - int high - - - - -Stores low in the low 32 bits of *pv and high in the high 32 bits of *pv. - - - - - - Bool XSyncValueGreaterThan - XSyncValue a - XSyncValue b - - - - -Returns True if a is greater than b, else returns -False. - - - - - Bool XSyncValueLessThan - XSyncValue a - XSyncValue b - - - - -Returns True if a is less than b, else returns -False. - - - - - - Bool XSyncValueGreaterOrEqual - XSyncValue a - XSyncValue b - - - - -Returns True if a is greater than or equal to b, -else returns False. - - - - - Bool XSyncValueLessOrEqual - XSyncValue a - XSyncValue b - - - - -Returns True if a is less than or equal to b, -else returns False. - - - - - Bool XSyncValueEqual - XSyncValue a - XSyncValue b - - - - -Returns True if a is equal to b, -else returns False. - - - - - Bool XSyncValueIsNegative - XSyncValue v - - - - -Returns True if v is negative, -else returns False. - - - - - Bool XSyncValueIsZero - XSyncValue v - - - - -Returns True if v is zero, -else returns False. - - - - - Bool XSyncValueIsPositive - XSyncValue v - - - - -Returns True if v is positive, -else returns False. - - - - - unsigned int XSyncValueLow32 - XSyncValue v - - - - -Returns the low 32 bits of v. - - - - - unsigned int XSyncValueHigh32 - XSyncValue v - - - - -Returns the high 32 bits of v. - - - - - void XSyncValueAdd - XSyncValue *presult - XSyncValue a - XSyncValue b - Bool *poverflow - - - - -Adds a to b and stores the result in *presult. If the result could not -fit in 64 bits, *poverflow is set to True, else it is -set to False. - - - - - void XSyncValueSubtract - XSyncValue *presult - XSyncValue a - XSyncValue b - Bool *poverflow - - - - -Subtracts b from a and stores the result in *presult. If the result could not -fit in 64 bits, *poverflow is set to True, else it is -set to False. - - - - - void XSyncMaxValue - XSyncValue *pv - - - - -Sets *pv to the maximum value expressible in 64 bits. - - - - - void XSyncMinValue - XSyncValue *pv - - - - -Sets *pv to the minimum value expressible in 64 bits. - - - - - -Events - - -Let event_base be the value event base return as defined in the function -XSyncQueryExtension. - - - -An XSyncCounterNotifyEvent’s type field has the value -event_base + XSyncCounterNotify. The fields of this -structure are: - - - -int type; /* event base + 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 */ - - - -An XSyncAlarmNotifyEvent’s type field has the value -event_base + XSyncAlarmNotify. The fields of -this structure are: - - - -int type; /* event_base + 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 */ - - - - - -Errors - -Let error_base be the value -error_base_return as defined in the function -XSyncQueryExtension. - - - -An XSyncAlarmError’s error_code field has -XSyncBadAlarm. The fields of this structure are: - - - -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 + XSyncBadAlarm */ -unsigned char request_code; /* Major op-code of failed request */ -unsigned char minor_code; /* Minor op-code of failed request */ - - - -An XSyncCounterError’s error code field has the value -error_base + XSyncBadCounter. The fields of this -structure are: - - -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 */ - - - - - + + + + + + + + + X Synchronization Extension Library + X Consortium Standard + X Version 11, Release 6.4 + + + TimGlauert + Olivetti Research/MultiWorks + + + Dave + Carver + Digital Equipment Corporation, MIT/Project Athena + + + Jim + Gettys + Digital Equipment Corporation, Cambridge Research Laboratory + + + David + Wiggins + X Consortium, Inc. + + + Version 3.0 + X Consortium + X Version 11, Release 6.4 + + + +Copyright 1991 by Olivetti Research Limited, Cambridge England and Digital Equipment Corporation, Maynard, Massachusetts + + + +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 © 1991 X Consortium, Inc. + + + +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. + + + + + + +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. + + + +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 Counter and +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 Await request that waits until +one of a set of synchronization conditions, called TRIGGERs, becomes TRUE. + + +The CreateCounter request allows a client to create +a Counter that can be changed by explicit +SetCounter and ChangeCounter +requests. These can be used to implement synchronization between +different clients. + + +There are some counters, called 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 Alarm mechanism that allows clients to receive an +event on a regular basis when a particular counter is changed. + + + + + +C Language Binding + + +The C routines provide direct access to the protocol and add no additional +semantics. + + +The include file for this extension is <X11/extensions/sync.h>. +Most of the names in the language binding are derived from the protocol +names by prepending XSync to the protocol name and changing the +capitalization. + + + +C Functions + + +Most of the following functions generate SYNC protocol requests. + + + + + Status XSyncQueryExtension + Display *dpy + int *event_base_return + int *error_base_return + + + + +If dpy supports the SYNC extension, +XSyncQueryExtension returns 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 False. + + + + + Status XSyncInitialize + Display *dpy + int *major_version_return + int *minor_version_return + + + + +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 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 False. +The only XSync function that may be called before this function is +XSyncQueryExtension. If a client violates this rule, the effects of all XSync +calls that it makes are undefined. + + + + + XSyncSystemCounter *XSyncListSystemCounters + Display *dpy + int *n_counters_return + + + + +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 +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. + + + +XSyncSystemCounter has the following fields: + + + +char * name; /* null-terminated name of system counter */ +XSyncCounter counter; /* counter id of this system counter */ +XSyncValue resolution; /* resolution of this system counter */ + + + + + void XSyncFreeSystemCounterList + XSyncSystemCounter *list + + + + +XSyncFreeSystemCounterList frees the memory +associated with the system counter list returned by +XSyncListSystemCounters. + + + + + XSyncCounter XSyncCreateCounter + Display *dpy + XSyncValue initial_value + + + + +XSyncCreateCounter creates a counter on the dpy +with the given initial value and returns the counter ID. It returns +None if dpy does not support the SYNC extension. + + + + + Status XSyncSetCounter + Display *dpy + XSyncCounter counter + XSyncValue value + + + + + +XSyncSetCounter sets counter to value. It returns +False if dpy does not +support the SYNC extension; otherwise, it returns True. + + + + + Status XSyncChangeCounter + Display *dpy + XSyncCounter counter + XSyncValue value + + + + +XSyncChangeCounter adds value to counter. It returns +False if dpy does not support the SYNC extension; +otherwise, it returns +True. + + + + Status XSyncDestroyCounter + Display *dpy + XSyncCounter counter + + + + +XSyncDestroyCounter destroys counter. It returns +False if dpy does not support the SYNC extension; +otherwise, it returns True. + + + + + Status XSyncQueryCounter + Display *dpy + XSyncCounter counter + XSyncValue *value_return + + + + +XSyncQueryCounter sets *value_return to the current +value of counter. It returns False if there was an +error during communication with the server or if dpy does not support the +SYNC extension; otherwise, it returns True. + + + + + Status XSyncAwait + Display *dpy + XSyncWaitCondition *wait_list + int n_conditions + + + + +XSyncAwait awaits on the conditions in wait_list. +The n_conditions is the number of wait conditions in wait_list. It +returns False if dpy does not support the SYNC +extension; otherwise, it returns True. The await is +processed asynchronously by the server; this function always returns +immediately after issuing the request. + + +XSyncWaitCondition has the following fields: + + + +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 */ + + + +XSyncValueType can be either +XSyncAbsolute or XSyncRelative. + + + +XSyncTestType can be one of +XSyncPositiveTransition, +XSyncNegativeTransition, +XSyncPositiveComparison, or +XSyncNegativeComparison. + + + + + XSyncAlarm XSyncCreateAlarm + Display *dpy + unsigned long values_mask + XSyncAlarmAttributes *values` + + + + +XSyncCreateAlarm creates an alarm and returns the +alarm ID. It returns None if the display does not support the SYNC +extension. The values_mask and values specify the alarm attributes. + + + +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 CreateAlarm for the +defaults. + + + +type field name attribute_mask +XSyncCounter trigger.counter; XSyncCACounter +XSyncValueType trigger.value_type; XSyncCAValueType +XSyncValue trigger.wait_value; XSyncCAValue +XSyncTestType trigger.test_type; XSyncCATestType +XSyncValue delta; XSyncCADelta +Bool events; XSyncCAEvents +XSyncAlarmState state; client cannot set this + + + + + Status XSyncDestroyAlarm + Display *dpy + XSyncAlarm alarm + + + + +XSyncDestroyAlarm destroys alarm. It returns +False if dpy does not support +the SYNC extension; otherwise, it returns True. + + + + + Status XSyncQueryAlarm + Display *dpy + XSyncAlarm alarm + XSyncAlarmAttributes *values_return + + + + + +XSyncQueryAlarm sets *values_return to the alarm’s +attributes. It returns False if there was an error +during communication with the server or if dpy does not support the +SYNC extension; otherwise, it returns True. + + + + + Status XSyncChangeAlarm + Display *dpy + XSyncAlarm alarm + unsigned long values_mask + XSyncAlarmAttributes *values + + + + +XSyncChangeAlarm changes alarm’s attributes. The +attributes to change are specified as in +XSyncCreateAlarm. It returns +False if dpy does not support +the SYNC extension; otherwise, it returns True. + + + + + Status XSyncSetPriority + Display *dpy + XID client_resource_id + int priority + + + + +XSyncSetPriority sets the priority of the client +owning client_resource_id to priority. If client_resource_id is None, it +sets the caller’s priority. It returns +False if dpy does not support the SYNC extension; +otherwise, it returns True. + + + + + Status XSyncGetPriority + Display *dpy + XID client_resource_id + int *return_priority + + + + +XSyncGetPriority sets *return_priority to the +priority of the client owning client_resource_id. If client_resource_id +is None, it sets *return_priority to the caller’s priority. It returns +False if there was an error during communication +with the server or if dpy does not support the SYNC extension; otherwise, it +returns True. + + + + + +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. + + + + + void XSyncIntToValue + XSyncValue *pv + int i + + + + +Converts i to an XSyncValue and stores it in *pv. +Performs sign extension (*pv will have the same sign as i.) + + + + + void XSyncIntsToValue + XSyncValue *pv + unsigned int low + int high + + + + +Stores low in the low 32 bits of *pv and high in the high 32 bits of *pv. + + + + + + Bool XSyncValueGreaterThan + XSyncValue a + XSyncValue b + + + + +Returns True if a is greater than b, else returns +False. + + + + + Bool XSyncValueLessThan + XSyncValue a + XSyncValue b + + + + +Returns True if a is less than b, else returns +False. + + + + + + Bool XSyncValueGreaterOrEqual + XSyncValue a + XSyncValue b + + + + +Returns True if a is greater than or equal to b, +else returns False. + + + + + Bool XSyncValueLessOrEqual + XSyncValue a + XSyncValue b + + + + +Returns True if a is less than or equal to b, +else returns False. + + + + + Bool XSyncValueEqual + XSyncValue a + XSyncValue b + + + + +Returns True if a is equal to b, +else returns False. + + + + + Bool XSyncValueIsNegative + XSyncValue v + + + + +Returns True if v is negative, +else returns False. + + + + + Bool XSyncValueIsZero + XSyncValue v + + + + +Returns True if v is zero, +else returns False. + + + + + Bool XSyncValueIsPositive + XSyncValue v + + + + +Returns True if v is positive, +else returns False. + + + + + unsigned int XSyncValueLow32 + XSyncValue v + + + + +Returns the low 32 bits of v. + + + + + unsigned int XSyncValueHigh32 + XSyncValue v + + + + +Returns the high 32 bits of v. + + + + + void XSyncValueAdd + XSyncValue *presult + XSyncValue a + XSyncValue b + Bool *poverflow + + + + +Adds a to b and stores the result in *presult. If the result could not +fit in 64 bits, *poverflow is set to True, else it is +set to False. + + + + + void XSyncValueSubtract + XSyncValue *presult + XSyncValue a + XSyncValue b + Bool *poverflow + + + + +Subtracts b from a and stores the result in *presult. If the result could not +fit in 64 bits, *poverflow is set to True, else it is +set to False. + + + + + void XSyncMaxValue + XSyncValue *pv + + + + +Sets *pv to the maximum value expressible in 64 bits. + + + + + void XSyncMinValue + XSyncValue *pv + + + + +Sets *pv to the minimum value expressible in 64 bits. + + + + + +Events + + +Let event_base be the value event base return as defined in the function +XSyncQueryExtension. + + + +An XSyncCounterNotifyEvent’s type field has the value +event_base + XSyncCounterNotify. The fields of this +structure are: + + + +int type; /* event base + 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 */ + + + +An XSyncAlarmNotifyEvent’s type field has the value +event_base + XSyncAlarmNotify. The fields of +this structure are: + + + +int type; /* event_base + 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 */ + + + + + +Errors + +Let error_base be the value +error_base_return as defined in the function +XSyncQueryExtension. + + + +An XSyncAlarmError’s error_code field has +XSyncBadAlarm. The fields of this structure are: + + + +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 + XSyncBadAlarm */ +unsigned char request_code; /* Major op-code of failed request */ +unsigned char minor_code; /* Minor op-code of failed request */ + + + +An XSyncCounterError’s error code field has the value +error_base + XSyncBadCounter. The fields of this +structure are: + + +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 */ + + + + + diff --git a/libXmu/doc/Xmu.xml b/libXmu/doc/Xmu.xml index bd79d6efc..8afe6882f 100644 --- a/libXmu/doc/Xmu.xml +++ b/libXmu/doc/Xmu.xml @@ -204,7 +204,7 @@ another round-trip to the server. XmuMakeAtom - + AtomPtr XmuMakeAtom const char *name @@ -233,7 +233,7 @@ can be used to cache the Atom value for one or more displays. XmuNameOfAtom - + char *XmuNameOfAtom AtomPtr atom_ptr @@ -255,7 +255,7 @@ The function returns the name of an AtomPtr. XmuInternAtom - + Atom XmuInternAtom Display *dpy @@ -291,7 +291,7 @@ such that subsequent requests do not cause another round-trip to the server. XmuGetAtomName - + char *XmuGetAtomName Display *dpy @@ -323,7 +323,7 @@ requests do not cause another round-trip to the server. XmuInternStrings - + void XmuInternStrings Display *dpy @@ -385,7 +385,7 @@ and link against the libXmu or libXmuu library. XmuPrintDefaultErrorMessage - + int XmuPrintDefaultErrorMessage Display *dpy diff --git a/mesalib/src/glsl/glsl_parser_extras.cpp b/mesalib/src/glsl/glsl_parser_extras.cpp index fce2faa75..d9aa300bb 100644 --- a/mesalib/src/glsl/glsl_parser_extras.cpp +++ b/mesalib/src/glsl/glsl_parser_extras.cpp @@ -436,7 +436,7 @@ ast_expression::print(void) const printf("? "); subexpressions[1]->print(); printf(": "); - subexpressions[1]->print(); + subexpressions[2]->print(); break; case ast_array_index: diff --git a/mesalib/src/glsl/ir_print_visitor.cpp b/mesalib/src/glsl/ir_print_visitor.cpp index 02f3d8149..5b5409daa 100644 --- a/mesalib/src/glsl/ir_print_visitor.cpp +++ b/mesalib/src/glsl/ir_print_visitor.cpp @@ -370,7 +370,7 @@ void ir_print_visitor::visit(ir_constant *ir) } else if (ir->type->is_record()) { ir_constant *value = (ir_constant *) ir->components.get_head(); for (unsigned i = 0; i < ir->type->length; i++) { - printf("(%s ", ir->type->fields.structure->name); + printf("(%s ", ir->type->fields.structure[i].name); value->accept(this); printf(")"); diff --git a/mesalib/src/mesa/drivers/dri/Makefile.defines b/mesalib/src/mesa/drivers/dri/Makefile.defines new file mode 100644 index 000000000..19b6de8b8 --- /dev/null +++ b/mesalib/src/mesa/drivers/dri/Makefile.defines @@ -0,0 +1,34 @@ +# -*-makefile-*- + +COMMON_GALLIUM_SOURCES = \ + ../common/utils.c \ + ../common/vblank.c \ + ../common/dri_util.c \ + ../common/xmlconfig.c + +COMMON_SOURCES = $(COMMON_GALLIUM_SOURCES) \ + ../../common/driverfuncs.c \ + ../common/texmem.c \ + ../common/drirenderbuffer.c + +INCLUDES = $(SHARED_INCLUDES) $(EXPAT_INCLUDES) + +OBJECTS = $(C_SOURCES:.c=.o) \ + $(CXX_SOURCES:.cpp=.o) \ + $(ASM_SOURCES:.S=.o) + + +### Include directories +SHARED_INCLUDES = \ + -I. \ + -I$(TOP)/src/mesa/drivers/dri/common \ + -Iserver \ + -I$(TOP)/include \ + -I$(TOP)/src/mapi \ + -I$(TOP)/src/mesa \ + -I$(TOP)/src/egl/main \ + -I$(TOP)/src/egl/drivers/dri \ + $(LIBDRM_CFLAGS) + +INCLUDES += $(API_DEFINES) +CXXFLAGS += $(API_DEFINES) diff --git a/mesalib/src/mesa/drivers/dri/Makefile.targets b/mesalib/src/mesa/drivers/dri/Makefile.targets new file mode 100644 index 000000000..436b2a3c4 --- /dev/null +++ b/mesalib/src/mesa/drivers/dri/Makefile.targets @@ -0,0 +1,78 @@ +# -*-makefile-*- + +##### RULES ##### + +.c.o: + $(CC) -c $(INCLUDES) $(DRI_CFLAGS) $(DRIVER_DEFINES) $< -o $@ + +.cpp.o: + $(CC) -c $(INCLUDES) $(DRI_CXXFLAGS) $(DRIVER_DEFINES) $< -o $@ + +.S.o: + $(CC) -c $(INCLUDES) $(DRI_CFLAGS) $(DRIVER_DEFINES) $< -o $@ + + +#### TARGETS ##### + +default: subdirs lib + + +.PHONY: lib +lib: symlinks subdirs depend + @$(MAKE) $(LIBNAME) $(TOP)/$(LIB_DIR)/$(LIBNAME) + +$(LIBNAME): $(OBJECTS) $(EXTRA_MODULES) $(MESA_MODULES) Makefile \ + $(TOP)/src/mesa/drivers/dri/Makefile.targets $(TOP)/src/mesa/drivers/dri/common/dri_test.o + $(MKLIB) -o $@.tmp -noprefix -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ + $(OBJECTS) $(EXTRA_MODULES) $(DRI_LIB_DEPS) + $(CXX) $(CFLAGS) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS) + @rm -f $@.test + mv -f $@.tmp $@ + + +$(TOP)/$(LIB_DIR)/$(LIBNAME): $(LIBNAME) + $(INSTALL) $(LIBNAME) $(TOP)/$(LIB_DIR) + + +# If the Makefile defined SUBDIRS, run make in each +.PHONY: subdirs +subdirs: + @if test -n "$(SUBDIRS)" ; then \ + for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE)) || exit 1; \ + fi \ + done \ + fi + + +.PHONY: symlinks +symlinks: + + +depend: $(C_SOURCES) $(CXX_SOURCES) $(ASM_SOURCES) $(SYMLINKS) + @ echo "running $(MKDEP)" + @ rm -f depend + @ touch depend + @ $(MKDEP) $(MKDEP_OPTIONS) $(DRIVER_DEFINES) $(INCLUDES) \ + $(C_SOURCES) $(CXX_SOURCES) \ + $(ASM_SOURCES) > /dev/null 2>/dev/null + + +# Emacs tags +tags: + etags `find . -name \*.[ch]` `find ../include` + + +# Remove .o and backup files +clean: + -rm -f *.o */*.o *~ *.so *~ server/*.o $(SYMLINKS) + -rm -f depend depend.bak + + +install: $(LIBNAME) + $(INSTALL) -d $(DESTDIR)$(DRI_DRIVER_INSTALL_DIR) + $(MINSTALL) -m 755 $(LIBNAME) $(DESTDIR)$(DRI_DRIVER_INSTALL_DIR) + + +-include depend diff --git a/xorg-server/xkeyboard-config/rules/base.xml.in b/xorg-server/xkeyboard-config/rules/base.xml.in index 7d4e2b9c9..0a0ca4588 100644 --- a/xorg-server/xkeyboard-config/rules/base.xml.in +++ b/xorg-server/xkeyboard-config/rules/base.xml.in @@ -627,6 +627,7 @@ logii350 <_description>Logitech Internet 350 Keyboard Logitech + 046d:c313 @@ -3026,12 +3027,6 @@ - - - qwerty - <_description>German (qwerty) - - ru diff --git a/xorg-server/xkeyboard-config/rules/xkb.dtd b/xorg-server/xkeyboard-config/rules/xkb.dtd index 0afa0df12..0a37b1188 100644 --- a/xorg-server/xkeyboard-config/rules/xkb.dtd +++ b/xorg-server/xkeyboard-config/rules/xkb.dtd @@ -32,7 +32,7 @@ - + @@ -53,3 +53,6 @@ + + + diff --git a/xorg-server/xkeyboard-config/symbols/de b/xorg-server/xkeyboard-config/symbols/de index 616b91303..7e052986b 100644 --- a/xorg-server/xkeyboard-config/symbols/de +++ b/xorg-server/xkeyboard-config/symbols/de @@ -485,21 +485,6 @@ xkb_symbols "dsb_qwertz" key { [ o, O, oacute, Oacute ] }; }; -partial alphanumeric_keys -xkb_symbols "qwerty" { - - // This layout should work exactly as a de with the exception - // of 'Z' and 'Y' keys, which are in the qwerty style (ie. swapped). - // 2008 by Matej Košík - - include "de(basic)" - - name[Group1] = "German (qwerty)"; - - key { [ z, Z, leftarrow, yen ] }; - key { [ y, Y, guillemotleft, less ] }; -}; - // layout for Russian letters on an german keyboard // based on US-RU layout by Ivan Popov 2005-07-17 // adopted for german layout by Alexey Fisher 2010-08-19 -- cgit v1.2.3