From 3744281b9ae8aa0ab86ceaee1afe8a603e3aeb2c Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 19 Nov 2012 10:16:38 +0100 Subject: dos -> unix --- xorg-server/hw/dmx/doc/DMXSpec-v1.txt | 916 ++++++++--------- xorg-server/hw/dmx/doc/DMXSpec.txt | 1750 ++++++++++++++++----------------- 2 files changed, 1333 insertions(+), 1333 deletions(-) (limited to 'xorg-server/hw/dmx/doc') diff --git a/xorg-server/hw/dmx/doc/DMXSpec-v1.txt b/xorg-server/hw/dmx/doc/DMXSpec-v1.txt index 19a50f2f5..cea97b9fe 100644 --- a/xorg-server/hw/dmx/doc/DMXSpec-v1.txt +++ b/xorg-server/hw/dmx/doc/DMXSpec-v1.txt @@ -1,458 +1,458 @@ - - - Client-to-Server DMX Extension to the X Protocol - - $Date$, $Revision$ - - Rickard E. (Rik) Faith (faith@redhat.com) - Kevin E. Martin (kem@redhat.com) - - Copyright 2002,2003 Red Hat Inc., Raleigh, North Carolina. - - 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 on the rights to use, copy, modify, - merge, publish, distribute, sublicense, and/or sell copies of the - Software, and to permit persons to whom the Software is furnished to - do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the - next paragraph) shall be included in all copies or substantial - portions of the Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS - 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. - - - -1. Overview - - The client-to-server DMX extension to the X protocol (DMX) provides - normal client applications with the ability to determine information - about the characteristics of the Xdmx server and the back-end X - servers that DMX is using. - - The name for this extension is "DMX". - - - -2. Syntactic conventions - - This document uses the same syntactic conventions requests and data - types as [X11R6.4]. - - - -3. Data types - - No new data types are defined by this extension. All data types - referenced in this document are defined in [X11R6.4]. - - - -4. Requests - - DMXQueryVersion - ==> - majorVersion: CARD32 - minorVersion: CARD32 - patchVersion: CARD32 - - The protocol this extension actually supports is indicated by - majorVersion and minorVersion (patchVersion indicates the - patchlevel and is for informational purposes only). - - Any incompatible changes to the protocol should be indicated by - incrementing majorVersion. - - Small, upward-compatible changes should be indicated by incrementing - minorVersion. - - Servers that support the protocol defined in this document will - return a majorVersion of 1 and a minorVersion of 1. - - - - DMXGetScreenCount - ==> - screenCount: CARD32 - - This request returns the number of back-end screens that the Xdmx - server controls. A back-end screen may be managed as a regular X - screen in the Xdmx server or may be joined with other back-end - screens using Xinerama. (The information returned by this request - does not change while Xdmx is running and may be cached on the - client side.) - - - - DMXGetScreenInformation - physicalScreen: CARD32 - ==> - displayName: STRING8 - width: CARD16 - height: CARD16 - xoffset: INT16 - yoffset: INT16 - logicalScreen: CARD32 - xorigin: INT16 - yorigin: INT16 - - Errors: Value - - This request returns information about individual back-end screens. - The physicalScreen value is between 0 and screenCount-1, inclusive - (values outside this range will result in a Value error). The - displayname is the name used to open the display, either from the - Xdmx command-line or from the configuration file. The width, - height, xoffset, and yoffset values comprise a geometry - specification (see X(7x)) for the location of the DMX window on the - back-end screen. This request will always return non-negative - (i.e., normalized) values for xoffset and yoffset. The - logicalScreen value is the value of the screen that that Xdmx server - exports to clients. When Xinerama is in use, this value is - typically 0 for all values of physicalScreen. If Xinerama is in - use, the xorigin and yorigin values specify where the physical - screen is positioned in the global Xinerama coordinate system. - Otherwise, these values are set to 0. (The information returned by - this request does not change while Xdmx is running and may be cached - on the client side.) - - - - DMXGetWindowInformation - window: CARD32 - ==> - screenCount: CARD32 - screens: LISTofCARD32 - windows: LISTofCARD32 - pos: LISTofRECTANGLE - vis: LISTofRECTANGLE - - Errors: Window, Alloc - - This request computed the return values incorrectly for version 1.0 - of this protocol. Version 1.1 of this protocol conforms to this - description. - - Given a window ID on the Xdmx server, this request returns data - about how the window is represented on the back-end X servers. For - each back-end X server that displays a portion of the window, the - following information is returned: - 1) the number of the physical screen containing that portion - (which can be used with the DMXGetScreenInformation request - to obtain more information about the screen), - 2) the window ID on the back-end X server of the window - containing that portion, - 3) the position and dimensions of the window on the back-end, in - screen coordinates, and - 4) the visible area of the window on the back-end, in - window-relative coordinates (all zeros for windows that are - not visible) - Note that DMX allows multiple back-end windows to overlap in their - view of the DMX logical window. Further, a logical window does not - have to be completely covered by back-end windows -- there may be - gaps. - - As an example, consider a 500x500 window that spans the top two - 1024x768 back-end displays (A and B) of a 2048x1536 DMX display - composed of 4 1024x768 back-end displays arranged in a cube: - A B - C D - - In this case, the DMXGetWindowInformation call would return the - following information for the 500x500 window: - - display A: 500x500 window at 1024-250,0 (relative to back end) - with 250x500 visible at 0,0 (relative to window origin) - - display B: 500x500 window at -250,0 (relative to back end) - with 250x500 visible at 250,0 (relative to window origin) - - display C: 500x500 window at 1024-250,-768 with 0x0 visible at 0,0 - - display D: 500x500 window at -250,-768 with 0x0 visible at 0,0 - - Note that if the specified window has not yet been mapped when - DMXGetWindowInformation is called, then a subsequent XMapWindow call - might be buffered in xlib while requests directly to the back-end X - servers are processed. This race condition can be solved by calling - DMXSync before talking directly to the back-end X servers. - - - DMXGetInputCount - ==> - inputCount: CARD32 - - This request was first supported in version 1.1 of this protocol. - - This request returns the number of input devices connected to the - Xdmx server. This number is the same as that returned by - XListInputDevices, but is available even when the XInput extension - is not supported. - - - - DMXGetInputInformation - deviceId: CARD32 - ==> - inputType: CARD32 - physicalScreen: CARD32 - physicalId: CARD32 - isCore: BOOL - sendsCore: BOOL - name: STRING8 - - Errors: Value - - This request was first supported in version 1.1 of this protocol. - - This request returns information about the specified input device - that cannot be obtained from the XListInputDeivices call. The - deviceId is the same as that used by the XListInputDevices call, and - must be in the range 0 to inputCount-1, inclusive (values outside - this range will result in a Value error). - - The value of inputType will always be value, and will be one of the - following values: - 0 for local (and dummy) devices, - 1 for console devices, and - 2 for back-end devices. - - For local devices, all other fields returned, except isCore and - sendsCore, are invalid. - - For console devices, the physicalScreen and physicalID will be - invalid, and the name will return the name of the X server on which - the console window is displayed. - - For back-end devices, the physicalScreen will identify the back-end - display and can be used as an argument to DMXGetScreenInformation to - obtain more information; the physicalId will be the XInput device id - on the back-end X server; and the name will be invalid (since it - does not provide any additional information that cannot be obtained - with DMXGetScreenInformation). - - If isCore is True, then this device is active as a true core input - device and will send core events. If sendsCore is True, then this - device queried an XInput extension device, but sends core events - instead of extension events. Note that this behavior is different - from that of XFree86, where XInput extension devices may send both - extension events and core events. - - - - DMXForceWindowCreation - window: CARD32 - ==> - - Errors: Window - - This request was first supported in version 1.2 of this protocol. - - When using the lazy window creation optimization, windows are not - created on the back-end X servers until they are required. This - request forces the immediate creation of the window requested. - - - - DMXReconfigureScreen - screen: CARD32 - x: INT16 - y: INT16 - ==> - status: CARD32 - - Errors: Value - - This request was first supported in version 1.3 of this protocol. - - This request reconfigures the screen position to coordinates (x,y) - when using the Xinerama extension. Otherwise, it is a NOP. Illegal - values for screen will result in a BadValue error. Other non-fatal - errors will be returned in status. - - - - DMXSync - ==> - - This request was first supported in version 1.5 of this protocol. - - This request flushes all pending protocol requests between the Xdmx - server and each back-end X server. It is used by a client that - talks directly to back-end X servers - - To ensure proper synchronization semantics, this request has a - reply, but the reply does not carry any information. - - - -5. Events - - No new events are defined by this extension. - - - -6. Errors - - No new events are defined by this extension. - - - -7. Encoding - - DMXQueryVersion - 1 CARD8 opcode (X assigned) - 1 0 DMX opcode (X_DMXQueryVersion) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 majorVersion - 4 CARD32 minorVersion - 4 CARD32 patchVersion - 12 unused - - DMXGetScreenCount - 1 CARD8 opcode (X assigned) - 1 1 DMX opcode (X_DMXGetScreenCount) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 screenCount - 20 unused - - DMXGetScreenInformation - 1 CARD8 opcode (X assigned) - 1 2 DMX opcode (X_DMXGetScreenInformation) - 2 2 request length - 4 CARD32 physicalScreen - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 n/4+p reply length - 4 n displayNameLength - 2 CARD16 width - 2 CARD16 height - 2 INT16 xoffset - 2 INT16 yoffset - 4 CARD32 logicalScreen - 2 INT16 xorigin - 2 INT16 yorigin - 4 unused - n displayName - p pad(n) - - DMXGetWindowInformation - 1 CARD8 opcode (X assigned) - 1 3 DMX opcode (X_DMXGetWindowInformation) - 2 2 request length - 4 CARD32 window - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 n*6 reply length - 4 n screenCount - 20 unused - n*4 LISTofCARD32 screens - n*4 LISTofCARD32 windows - n*8 LISTofRECTANGLE pos - n*8 LISTofRECTANGLE vis - - DMXGetInputCount - 1 CARD8 opcode (X assigned) - 1 DMX opcode (X_DMXGetInputCount) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 inputCount - 20 unused - - DMXGetInputInformation - 1 CARD8 opcode (X assigned) - 1 4 DMX opcode (X_DMXGetInputInformation) - 2 2 request length - 4 CARD32 deviceId - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 n/4+p reply length - 4 CARD32 inputType - 4 CARD32 physicalScreen - 4 CARD32 physicalId - 4 n nameLength - 1 BOOL isCore - 1 BOOL sendsCore - 6 unused - n name - p pad(n) - - DMXForceWindowCreation - 1 CARD8 opcode (X assigned) - 1 2 DMX opcode (X_DMXForceWindowCreation) - 2 2 request length - 4 CARD32 window - ==> - - DMXReconfigureScreen - 1 CARD8 opcode (X assigned) - 1 2 DMX opcode (X_DMXReconfigureScreen) - 2 2 request length - 4 CARD32 screen - 2 INT16 x - 2 INT16 y - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - DMXSync - 1 CARD8 opcode (X assigned) - 1 0 DMX opcode (X_DMXSync) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 24 unused - - -8. Changes to existing requests/replies/events - - No changes to existing requests, replies, or events are necessitated - by this extension. - - - -9. Acknowledgments - - - -10. References - - [X11R6.4] Robert W. Sheifler. X Window System Protocol, X Consortium - Standard, X Version 11, Release 6.4. Available from - xc/doc/specs/XProtocol and xc/doc/hardcopy/XProtocol. + + + Client-to-Server DMX Extension to the X Protocol + + $Date$, $Revision$ + + Rickard E. (Rik) Faith (faith@redhat.com) + Kevin E. Martin (kem@redhat.com) + + Copyright 2002,2003 Red Hat Inc., Raleigh, North Carolina. + + 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 on the rights to use, copy, modify, + merge, publish, distribute, sublicense, and/or sell copies of the + Software, and to permit persons to whom the Software is furnished to + do so, subject to the following conditions: + + The above copyright notice and this permission notice (including the + next paragraph) shall be included in all copies or substantial + portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS + 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. + + + +1. Overview + + The client-to-server DMX extension to the X protocol (DMX) provides + normal client applications with the ability to determine information + about the characteristics of the Xdmx server and the back-end X + servers that DMX is using. + + The name for this extension is "DMX". + + + +2. Syntactic conventions + + This document uses the same syntactic conventions requests and data + types as [X11R6.4]. + + + +3. Data types + + No new data types are defined by this extension. All data types + referenced in this document are defined in [X11R6.4]. + + + +4. Requests + + DMXQueryVersion + ==> + majorVersion: CARD32 + minorVersion: CARD32 + patchVersion: CARD32 + + The protocol this extension actually supports is indicated by + majorVersion and minorVersion (patchVersion indicates the + patchlevel and is for informational purposes only). + + Any incompatible changes to the protocol should be indicated by + incrementing majorVersion. + + Small, upward-compatible changes should be indicated by incrementing + minorVersion. + + Servers that support the protocol defined in this document will + return a majorVersion of 1 and a minorVersion of 1. + + + + DMXGetScreenCount + ==> + screenCount: CARD32 + + This request returns the number of back-end screens that the Xdmx + server controls. A back-end screen may be managed as a regular X + screen in the Xdmx server or may be joined with other back-end + screens using Xinerama. (The information returned by this request + does not change while Xdmx is running and may be cached on the + client side.) + + + + DMXGetScreenInformation + physicalScreen: CARD32 + ==> + displayName: STRING8 + width: CARD16 + height: CARD16 + xoffset: INT16 + yoffset: INT16 + logicalScreen: CARD32 + xorigin: INT16 + yorigin: INT16 + + Errors: Value + + This request returns information about individual back-end screens. + The physicalScreen value is between 0 and screenCount-1, inclusive + (values outside this range will result in a Value error). The + displayname is the name used to open the display, either from the + Xdmx command-line or from the configuration file. The width, + height, xoffset, and yoffset values comprise a geometry + specification (see X(7x)) for the location of the DMX window on the + back-end screen. This request will always return non-negative + (i.e., normalized) values for xoffset and yoffset. The + logicalScreen value is the value of the screen that that Xdmx server + exports to clients. When Xinerama is in use, this value is + typically 0 for all values of physicalScreen. If Xinerama is in + use, the xorigin and yorigin values specify where the physical + screen is positioned in the global Xinerama coordinate system. + Otherwise, these values are set to 0. (The information returned by + this request does not change while Xdmx is running and may be cached + on the client side.) + + + + DMXGetWindowInformation + window: CARD32 + ==> + screenCount: CARD32 + screens: LISTofCARD32 + windows: LISTofCARD32 + pos: LISTofRECTANGLE + vis: LISTofRECTANGLE + + Errors: Window, Alloc + + This request computed the return values incorrectly for version 1.0 + of this protocol. Version 1.1 of this protocol conforms to this + description. + + Given a window ID on the Xdmx server, this request returns data + about how the window is represented on the back-end X servers. For + each back-end X server that displays a portion of the window, the + following information is returned: + 1) the number of the physical screen containing that portion + (which can be used with the DMXGetScreenInformation request + to obtain more information about the screen), + 2) the window ID on the back-end X server of the window + containing that portion, + 3) the position and dimensions of the window on the back-end, in + screen coordinates, and + 4) the visible area of the window on the back-end, in + window-relative coordinates (all zeros for windows that are + not visible) + Note that DMX allows multiple back-end windows to overlap in their + view of the DMX logical window. Further, a logical window does not + have to be completely covered by back-end windows -- there may be + gaps. + + As an example, consider a 500x500 window that spans the top two + 1024x768 back-end displays (A and B) of a 2048x1536 DMX display + composed of 4 1024x768 back-end displays arranged in a cube: + A B + C D + + In this case, the DMXGetWindowInformation call would return the + following information for the 500x500 window: + + display A: 500x500 window at 1024-250,0 (relative to back end) + with 250x500 visible at 0,0 (relative to window origin) + + display B: 500x500 window at -250,0 (relative to back end) + with 250x500 visible at 250,0 (relative to window origin) + + display C: 500x500 window at 1024-250,-768 with 0x0 visible at 0,0 + + display D: 500x500 window at -250,-768 with 0x0 visible at 0,0 + + Note that if the specified window has not yet been mapped when + DMXGetWindowInformation is called, then a subsequent XMapWindow call + might be buffered in xlib while requests directly to the back-end X + servers are processed. This race condition can be solved by calling + DMXSync before talking directly to the back-end X servers. + + + DMXGetInputCount + ==> + inputCount: CARD32 + + This request was first supported in version 1.1 of this protocol. + + This request returns the number of input devices connected to the + Xdmx server. This number is the same as that returned by + XListInputDevices, but is available even when the XInput extension + is not supported. + + + + DMXGetInputInformation + deviceId: CARD32 + ==> + inputType: CARD32 + physicalScreen: CARD32 + physicalId: CARD32 + isCore: BOOL + sendsCore: BOOL + name: STRING8 + + Errors: Value + + This request was first supported in version 1.1 of this protocol. + + This request returns information about the specified input device + that cannot be obtained from the XListInputDeivices call. The + deviceId is the same as that used by the XListInputDevices call, and + must be in the range 0 to inputCount-1, inclusive (values outside + this range will result in a Value error). + + The value of inputType will always be value, and will be one of the + following values: + 0 for local (and dummy) devices, + 1 for console devices, and + 2 for back-end devices. + + For local devices, all other fields returned, except isCore and + sendsCore, are invalid. + + For console devices, the physicalScreen and physicalID will be + invalid, and the name will return the name of the X server on which + the console window is displayed. + + For back-end devices, the physicalScreen will identify the back-end + display and can be used as an argument to DMXGetScreenInformation to + obtain more information; the physicalId will be the XInput device id + on the back-end X server; and the name will be invalid (since it + does not provide any additional information that cannot be obtained + with DMXGetScreenInformation). + + If isCore is True, then this device is active as a true core input + device and will send core events. If sendsCore is True, then this + device queried an XInput extension device, but sends core events + instead of extension events. Note that this behavior is different + from that of XFree86, where XInput extension devices may send both + extension events and core events. + + + + DMXForceWindowCreation + window: CARD32 + ==> + + Errors: Window + + This request was first supported in version 1.2 of this protocol. + + When using the lazy window creation optimization, windows are not + created on the back-end X servers until they are required. This + request forces the immediate creation of the window requested. + + + + DMXReconfigureScreen + screen: CARD32 + x: INT16 + y: INT16 + ==> + status: CARD32 + + Errors: Value + + This request was first supported in version 1.3 of this protocol. + + This request reconfigures the screen position to coordinates (x,y) + when using the Xinerama extension. Otherwise, it is a NOP. Illegal + values for screen will result in a BadValue error. Other non-fatal + errors will be returned in status. + + + + DMXSync + ==> + + This request was first supported in version 1.5 of this protocol. + + This request flushes all pending protocol requests between the Xdmx + server and each back-end X server. It is used by a client that + talks directly to back-end X servers + + To ensure proper synchronization semantics, this request has a + reply, but the reply does not carry any information. + + + +5. Events + + No new events are defined by this extension. + + + +6. Errors + + No new events are defined by this extension. + + + +7. Encoding + + DMXQueryVersion + 1 CARD8 opcode (X assigned) + 1 0 DMX opcode (X_DMXQueryVersion) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 majorVersion + 4 CARD32 minorVersion + 4 CARD32 patchVersion + 12 unused + + DMXGetScreenCount + 1 CARD8 opcode (X assigned) + 1 1 DMX opcode (X_DMXGetScreenCount) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 screenCount + 20 unused + + DMXGetScreenInformation + 1 CARD8 opcode (X assigned) + 1 2 DMX opcode (X_DMXGetScreenInformation) + 2 2 request length + 4 CARD32 physicalScreen + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 n/4+p reply length + 4 n displayNameLength + 2 CARD16 width + 2 CARD16 height + 2 INT16 xoffset + 2 INT16 yoffset + 4 CARD32 logicalScreen + 2 INT16 xorigin + 2 INT16 yorigin + 4 unused + n displayName + p pad(n) + + DMXGetWindowInformation + 1 CARD8 opcode (X assigned) + 1 3 DMX opcode (X_DMXGetWindowInformation) + 2 2 request length + 4 CARD32 window + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 n*6 reply length + 4 n screenCount + 20 unused + n*4 LISTofCARD32 screens + n*4 LISTofCARD32 windows + n*8 LISTofRECTANGLE pos + n*8 LISTofRECTANGLE vis + + DMXGetInputCount + 1 CARD8 opcode (X assigned) + 1 DMX opcode (X_DMXGetInputCount) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 inputCount + 20 unused + + DMXGetInputInformation + 1 CARD8 opcode (X assigned) + 1 4 DMX opcode (X_DMXGetInputInformation) + 2 2 request length + 4 CARD32 deviceId + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 n/4+p reply length + 4 CARD32 inputType + 4 CARD32 physicalScreen + 4 CARD32 physicalId + 4 n nameLength + 1 BOOL isCore + 1 BOOL sendsCore + 6 unused + n name + p pad(n) + + DMXForceWindowCreation + 1 CARD8 opcode (X assigned) + 1 2 DMX opcode (X_DMXForceWindowCreation) + 2 2 request length + 4 CARD32 window + ==> + + DMXReconfigureScreen + 1 CARD8 opcode (X assigned) + 1 2 DMX opcode (X_DMXReconfigureScreen) + 2 2 request length + 4 CARD32 screen + 2 INT16 x + 2 INT16 y + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + DMXSync + 1 CARD8 opcode (X assigned) + 1 0 DMX opcode (X_DMXSync) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 24 unused + + +8. Changes to existing requests/replies/events + + No changes to existing requests, replies, or events are necessitated + by this extension. + + + +9. Acknowledgments + + + +10. References + + [X11R6.4] Robert W. Sheifler. X Window System Protocol, X Consortium + Standard, X Version 11, Release 6.4. Available from + xc/doc/specs/XProtocol and xc/doc/hardcopy/XProtocol. diff --git a/xorg-server/hw/dmx/doc/DMXSpec.txt b/xorg-server/hw/dmx/doc/DMXSpec.txt index 078f83e26..4009f1210 100644 --- a/xorg-server/hw/dmx/doc/DMXSpec.txt +++ b/xorg-server/hw/dmx/doc/DMXSpec.txt @@ -1,875 +1,875 @@ - - - Client-to-Server DMX Extension to the X Protocol - - $Date$, $Revision$ - - Rickard E. (Rik) Faith (faith@redhat.com) - Kevin E. Martin (kem@redhat.com) - - Copyright 2002-2004 Red Hat Inc., Raleigh, North Carolina. - - 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 on the rights to use, copy, modify, - merge, publish, distribute, sublicense, and/or sell copies of the - Software, and to permit persons to whom the Software is furnished to - do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the - next paragraph) shall be included in all copies or substantial - portions of the Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS - 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. - - - -1. Overview - - The client-to-server DMX extension to the X protocol (DMX) provides - normal client applications with the ability to determine information - about the characteristics of the Xdmx server and the back-end X - servers that DMX is using. - - The name for this extension is "DMX". - - - -2. Syntactic conventions - - This document uses the same syntactic conventions requests and data - types as [X11R6.4]. - - - -3. Data types - - No new data types are defined by this extension. All data types - referenced in this document are defined in [X11R6.4]. - - - -4. Requests - - DMXQueryVersion - ==> - majorVersion: CARD32 - minorVersion: CARD32 - patchVersion: CARD32 - - Errors: None - - The protocol this extension actually supports is indicated by - majorVersion and minorVersion (patchVersion indicates the - patchlevel and is for informational purposes only). - - Any incompatible changes to the protocol should be indicated by - incrementing majorVersion. - - Small, upward-compatible changes should be indicated by incrementing - minorVersion. - - Servers that support the protocol defined in this document will - return a majorVersion of 2 and a minorVersion of 2. - - (Version 1.5 was the last version in the 1.x series; version 2.0 was - a testing version that was poorly defined.) - - - - DMXSync - ==> - status: CARD32 - - Errors: None - - This request was first supported in version 1.5 of this protocol. - The status field in the reply was introduced in version 2.0 of this - protocol. Since the status field is ignored, no changes to the - underlying protocol were required. - - This request flushes all pending protocol requests between the Xdmx - server and each back-end X server. It is used by clients that - talk directly to back-end X servers to ensure that all pending Xdmx - requests have reached all back-end servers and have been processed - by those servers. - - The value of status is always 0. - - - - DMXForceWindowCreation - window: CARD32 - ==> - status: CARD32 - - Errors: Window - - This request was first supported in version 1.2 of this protocol. - This request was changed to have a reply in version 2.0 of this - protocol. The old version of this request was deprecated and will - return BadImplementation. - - When using the lazy window creation optimization, windows are not - created on the back-end X servers until they are required. This - request forces the immediate creation of the window requested. - - The value of status is always 0. - - - - - DMXGetScreenCount - ==> - screenCount: CARD32 - - Errors: None - - This request returns the number of screens that the Xdmx server - controls. Since a DMX screen usually fills all of the available - area on a back-end server, there is usually a one-to-one - correspondence between DMX screens and backend servers. However, it - is also possible for a DMX screen to cover only part of the - available area on a back-end server, and for more than one DMX - screen to occupy different parts of the visible area on the same - back-end server. - - A DMX screen may be managed as a regular X screen in the Xdmx server - or may be joined with other DMX screens using Xinerama. - - - - DMXGetScreenAttributes - physicalScreen: CARD32 - ==> - displayName: STRING8 - logicalScreen: CARD32 - screenWindowWidth: CARD16 - screenWindowHeight: CARD16 - screenWindowXoffset: INT16 - screenWindowYoffset: INT16 - rootWindowWidth: CARD16 - rootWindowHeight: CARD16 - rootWindowXoffset: INT16 - rootWindowYoffset: INT16 - rootWindowXorigin: INT16 - rootWindowYorigin: INT16 - - Errors: Value - - This request is new in version 2.0 of this protocol. The old - DMXGetScreenInformation request is deprecated and will now return - BadImplementation. - - This request returns attributes about a single DMX screen. - - The physicalScreen value is between 0 and screenCount-1, inclusive - (values outside this range will result in a Value error). - - The displayname is the name used to open the display, either from - the Xdmx command-line or from the configuration file. - - The logicalScreen value is the value of the screen that that Xdmx - server exports to clients. When Xinerama is in use, this value is - typically 0 for all values of physicalScreen. If Xinerama is in - use, the rootWindowXOrigin and rootWindowYOrigin values specify - where the physical screen is positioned in the global Xinerama - coordinate system. Otherwise, these values are set to 0. - - The screenWindow values comprise a geometry specification (see - X(7x)) for the location of the DMX screen on the back-end screen. - The coordinant system of the back-end display is used. - - The first four rootWindow values comprise a geometry specification - (see X(7x)) for the location of the root window on the screen - window. The coordinant system of the screen window is used. In - most cases, the root window will have the same geometry as the DMX - screen window, and will occupy the same area of the back-end - display. (This would not be the case, for example, if automatic - projector alignment is used.) - - - - DMXChangeScreensAttributes - screenCount: CARD32 - maskCount: CARD32 - screens: LISTofCARD32 - valueMasks: LISTofCARD32 - valueList: LISTofVALUES - ==> - status: CARD32 - errorScreen: CARD32 - - Errors: Length, Alloc - - This request was first supported in version 2.0 of this protocol. - (A singular version of this request with the ability to change some - RootWindow attributes was supported in version 1.3 of this protocol, - has been deprecated, and will return BadImplementation.) - - This request changes the geometries and positions of the DMX screen - and DMX root windows on the back-end X servers. - - The valueMask and valueList specify which attributes are to be - changed. The possible values are: - - Attribute Type - - ScreenWindowWidth CARD16 - ScreenWindowHeight CARD16 - ScreenWindowXoffset INT16 - ScreenWindowYoffset INT16 - RootWindowWidth CARD16 - RootWindowHeight CARD16 - RootWindowXoffset INT16 - RootWindowYoffset INT16 - RootWindowXorigin INT16 - RootWindowYorigin INT16 - - The attribute values have the same meaning as do the corresponding - values for DMXGetScreenAttributes. - - Non-fatal errors will be returned in status (0 otherwise): - DmxBadXinerama: Xinerama is not active - DmxBadValue: The resulting position is not allowed - (e.g., one corner is outside the bounding box) - On error, errorScreen will contain the number of the screen that - caused the first error. - - - - DMXAddScreen - displayName: STRING8 - physicalScreen: CARD32 - valueMask: CARD32 - valueList: LISTofVALUES - ==> - status: CARD32 - physicalScreen: CARD32 - - Errors: Length, Alloc, Value - - This request was first supported in version 2.2 of this protocol. - - This request re-attaches the back-end physicalScreen to the Xdmx - server. Only back-end screens that have been previously detached - with DMXRemoveScreen may be added. The name of the back-end display - is given in displayName, and this will replace the name of the - back-end screen that was detached. Both the displayName and - physicalScreen must be correct for this request to work. - - The valueMask and valueList specify the attributes to be used. The - possible values are: - - Attribute Type - - ScreenWindowWidth CARD16 - ScreenWindowHeight CARD16 - ScreenWindowXoffset INT16 - ScreenWindowYoffset INT16 - RootWindowWidth CARD16 - RootWindowHeight CARD16 - RootWindowXoffset INT16 - RootWindowYoffset INT16 - RootWindowXorigin INT16 - RootWindowYorigin INT16 - - The attribute values have the same meaning as do the corresponding - values for DMXGetScreenAttributes. - - On success, status will be 0 and physicalScreen will contain the new - screen number. On failure, status will be non-zero. The status - will be 1 if any of the following occured: - * the -addremovescreens command-line option was not specified on - the Xdmx command line - * the value of physicalScreen is out of range - * physicalScreen has not been detached (with DMXRemoveScreen) - * displayName cannot be opened - * the visuals of displayname do not match the visuals that Xdmx - is using - * the screen data for displayName does not match the data for the - previously removed display - The status will be DmxBadValue if the attribute values are out of - range. - - - - DMXRemoveScreen - physicalScreen: CARD32 - ==> - status: CARD32 - - Errors: None - - This request was first supported in version 2.2 of this protocol. - - This request detaches the physicalScreen screen. - - On success, status will be 0. On failure, the status will 1 if any - of the following occur: - * the -addremovescreens command-line option was not specified on - the Xdmx command line - * the value of physicalScreen is out of range - * the back-end screen has already been detached. - - - - DMXGetWindowAttributes - window: CARD32 - ==> - screenCount: CARD32 - screens: LISTofCARD32 - windows: LISTofCARD32 - pos: LISTofRECTANGLE - vis: LISTofRECTANGLE - - Errors: Window, Alloc - - This request computes the return values incorrectly for version 1.0 - of this protocol. Version 1.1 of this protocol conforms to this - description. In version 2.0, the name of this request was changed - from DMXGetWindowInformation. However, since the request itself did - not change, no changes to the underlying protocol were made. - - Given a window ID on the Xdmx server, this request returns data - about how the window is represented on the back-end X servers. For - each back-end X server that displays a portion of the window, the - following information is returned: - 1) the number of the physical screen containing that portion - (which can be used with the DMXGetScreenAttributes request - to obtain more information about the screen), - 2) the window ID on the back-end X server of the window - containing that portion, - 3) the position and dimensions of the window on the back-end, in - screen coordinates, and - 4) the visible area of the window on the back-end, in - window-relative coordinates (all zeros for windows that are - not visible). - Note that DMX allows multiple back-end windows to overlap in their - view of the DMX logical window. Further, a logical window does not - have to be completely covered by back-end windows -- there may be - gaps. - - As an example, consider a 500x500 window that spans the top two - 1024x768 back-end displays (A and B) of a 2048x1536 DMX display - composed of 4 1024x768 back-end displays arranged in a cube: - A B - C D - - In this case, the DMXGetWindowAttributes call would return the - following information for the 500x500 window: - - display A: 500x500 window at 1024-250,0 (relative to back end) - with 250x500 visible at 0,0 (relative to window origin) - - display B: 500x500 window at -250,0 (relative to back end) - with 250x500 visible at 250,0 (relative to window origin) - - display C: 500x500 window at 1024-250,-768 with 0x0 visible at 0,0 - - display D: 500x500 window at -250,-768 with 0x0 visible at 0,0 - - Note that if the specified window has not yet been mapped when - DMXGetWindowAttributes is called, then a subsequent XMapWindow call - might be buffered in xlib while requests directly to the back-end X - servers are processed. This race condition can be solved by calling - DMXSync before talking directly to the back-end X servers. - - - - DMXGetDesktopAttributes - ==> - width: INT16 - height: INT16 - shiftX: INT16 - shiftY: INT16 - - Errors: None - - This request was first supported in version 2.0 of this protocol. - - This request returns the size of the bounding box of the whole - screen in width and height. The shiftX and shiftY values will - always be 0. The global bounding box is computed whether or not - Xinerama is active, and may be larger than the Xinerama screen size - because of information in the configuration file. - - - - DMXChangeDesktopAttributes - valueMask: BITMASK - valueList: LISTofVALUE - ==> - status: CARD32 - - Errors: Length, Value - - This request was first supported in version 2.0 of this protocol. - - This request resizes the bounding box of the whole screen when using - the Xinerama extension. Otherwise, it has no effect on the screen - layout. The valueMask and valueList specify which attributes are to - be changed. The possible values are: - - Attriubute Type - - Width INT16 - Height INT16 - ShiftX INT16 - ShiftY INT16 - - Width and Height specify the new width and height for the bounding - box. ShiftX and ShiftY specify where the Xinerama origin will be - placed with respect to the origin of the new bounding box. This - allows the left and upper edges of the bounding box to be changed - without changing the visual position of the windows on the desktop. - If Width or Height is not specified, the current values will be - used. If ShiftX or ShiftY is not specified, 0 will be used. - - All coordinants are in the global DMX coordinant system. If - Xinerama is not active, this request is not useful. - - Non-fatal errors will be returned in status (0 otherwise): - DmxBadXinerama: Xinerama is not active - DmxBadValue: The size of the bounding box is too large - - - - DMXGetInputCount - ==> - inputCount: CARD32 - - This request was first supported in version 1.1 of this protocol. - - This request returns the number of input devices connected to the - Xdmx server. This number is the same as that returned by - XListInputDevices, but is available even when the XInput extension - is not supported. - - - - DMXGetInputAttributes - deviceId: CARD32 - ==> - inputType: CARD32 - physicalScreen: CARD32 - physicalId: CARD32 - isCore: BOOL - sendsCore: BOOL - detached: BOOL - name: STRING8 - - Errors: Value - - This request was first supported in version 1.1 of this protocol. - In version 2.0, the name of this request was changed from - DMXGetInputInformation. However, since the request itself did not - change, no changes to the underlying protocol were made. In version - 2.2, the name of detached was changed from reservation. There was - no change in underlying protocol. - - This request returns information about the specified input device - that cannot be obtained from the XListInputDeivices call. The - deviceId is the same as that used by the XListInputDevices call, and - must be in the range 0 to inputCount-1, inclusive (values outside - this range will result in a Value error). - - The value of inputType will always be valid, and will be one of the - following values: - 0 for local (and dummy) devices, - 1 for console devices, and - 2 for back-end devices. - - For local devices, all other fields returned, except isCore and - sendsCore, are invalid. - - For console devices, the physicalScreen and physicalID will be - invalid, and the name will return the name of the X server on which - the console window is displayed. - - For back-end devices, the physicalScreen will identify the back-end - display and can be used as an argument to DMXGetScreenAttributes to - obtain more information; the physicalId will be the XInput device id - on the back-end X server; and the name will be invalid (since it - does not provide any additional information that cannot be obtained - with DMXGetScreenAttributes). - - If isCore is True, then this device is active as a true core input - device and will send core events. If sendsCore is True, then this - device is an XInput extension device, but sends core events instead - of extension events. Note that this behavior is different from that - of XFree86 or Xorg, where XInput extension devices may send both - extension events and core events. - - If detached is True, then this device has been detached and is no - longer producing input events. The device may be reattached using - DMXAddInput. - - - - DMXAddInput - displayName: STRING8 - valueMask: CARD32 - valueList: LISTofVALUES - ==> - status: CARD32 - physicalId: CARD32 - - Errors: Value, Access - - This request was first supported in version 2.2 of this protocol. - - The valueMask and valueList specify the attributes to be used. The - possible values are: - - Attribute Type - - InputType CARD32 - InputPhysicalScreen CARD32 - InputSendsCore BOOL - - This request attaches an input device to the Xdmx server. The value - of inputType will be one: - 1 for console devices, and - 2 for back-end devices. - Other values of InputType will return a BadValue error. Local - devices (inputType=0 in DMXGetInputAttributes) cannot be attached or - removed. For console devices, displayName will store the name of - the display to be used. - - For back-end devices, InputPhysicalScreen will specify the screen - number. BadValue will be returned if the screen number is out of - range. BadAccess will be returned if the input has already been - attached or if the backend screen is currently detached. - - If InputSendsCore is True, the new device will be added as a true - core device. - - If a device was removed with DMXRemoveInput an attempt will be made - to reconnect the previous devices (InputSendsCore is ignored in this - case). - - - - DMXRemoveInput - physicalId: CARD32 - ==> - status: CARD32 - - Errors: Value, Access - - This request was first supported in version 2.2 of this protocol. - - This request detaches the input device with physicalId, and all - associated inputs (e.g., if the physicalId is a backend mouse, and a - keyboard is also attached to the backend, then both devices will be - detached). If the physicalId is outside the valid range (0 to one - less than the value returned by DMXInputCount), BadValue is - returned. If the physicalId has already been detached, BadAccess is - returned. The status is always 0. - - - -5. Events - - No new events are defined by this extension. - - - -6. Errors - - No new events are defined by this extension. - - - -7. Encoding - - Deprecated DMX opcodes: - DMXGetScreenInformation 2 - DMXForceWindowCreation 6 - DMXReconfigureScreen 7 - - Valid DMX opcodes: - DMXQueryVersion 0 - DMXSync 8 - DMXForceWindowCreation 9 - - DMXGetScreenCount 1 - DMXGetScreenAttributes 10 - DMXChangeScreensAttributes 11 - DMXAddScreen 12 - DMXRemoveScreen 13 - - DMXGetWindowAttributes 3 - - DMXGetDesktopAttributes 14 - DMXChangeDesktopAttributes 15 - - DMXGetInputCount 4 - DMXGetInputAttributes 5 - DMXAddInput 16 - DMXRemoveInput 17 - - DMXQueryVersion - 1 CARD8 opcode (X assigned) - 1 0 DMX opcode (X_DMXQueryVersion) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 majorVersion - 4 CARD32 minorVersion - 4 CARD32 patchVersion - 12 unused - - DMXSync - 1 CARD8 opcode (X assigned) - 1 8 DMX opcode (X_DMXSync) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - DMXForceWindowCreation - 1 CARD8 opcode (X assigned) - 1 9 DMX opcode (X_DMXForceWindowCreation) - 2 2 request length - 4 CARD32 window - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - - DMXGetScreenCount - 1 CARD8 opcode (X assigned) - 1 1 DMX opcode (X_DMXGetScreenCount) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 screenCount - 20 unused - - DMXGetScreenAttributes - 1 CARD8 opcode (X assigned) - 1 10 DMX opcode (X_DMXGetScreenAttributes) - 2 2 request length - 4 CARD32 physicalScreen - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 1+(n+p)/4 reply length - 4 n displayNameLength - 4 CARD32 logicalScreen - 2 CARD16 screenWindowWidth - 2 CARD16 screenWindowHeight - 2 INT16 screenWindowXoffset - 2 INT16 screenWindowYoffset - 2 CARD16 rootWindowWidth - 2 CARD16 rootWindowHeight - 2 INT16 rootWindowXoffset - 2 INT16 rootWindowYoffset - 2 INT16 rootWindowXorigin - 2 INT16 rootWindowYorigin - n displayName - p pad(n) - - DMXChangeScreensAttributes - 1 CARD8 opcode (X assigned) - 1 11 DMX opcode (X_DMXChangeScreenAttributes) - 2 3+s+m+n request length - 4 s screenCount - 4 m maskCount - 4s LISTofCARD32 screens - 4m LISTofCARD32 valueMasks - 4n LISTofVALUES valueList - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 4 CARD32 errorScreen - 16 unused - - - DMXAddScreen - 1 CARD8 opcode (X assigned) - 1 12 DMX opcode (X_DMXAddScreen) - 2 3+m+(n+p)/4 request length - 4 n displayNameLength - 4 CARD32 physicalScreen - 4 CARD32 valueMask - 4m LISTofVALUES valueList - n displayName - p pad(n) - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 4 CARD32 physicalScreen - 16 unused - - DMXRemoveScreen - 1 CARD8 opcode (X assigned) - 1 13 DMX opcode (X_DMXRemoveScreen) - 2 2 request length - 4 CARD32 physicalScreen - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - DMXGetWindowAttributes - 1 CARD8 opcode (X assigned) - 1 3 DMX opcode (X_DMXGetWindowAttributes) - 2 2 request length - 4 CARD32 window - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 n*6 reply length - 4 n screenCount - 20 unused - n*4 LISTofCARD32 screens - n*4 LISTofCARD32 windows - n*8 LISTofRECTANGLE pos - n*8 LISTofRECTANGLE vis - - DMXGetDesktopAttributes - 1 CARD8 opcode (X assigned) - 1 14 DMX opcode (X_DMXGetDesktopAttributes) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 2 INT16 width - 2 INT16 height - 2 INT16 shiftX - 2 INT16 shiftY - 16 unused - - DMXChangeDesktopAttributes - 1 CARD8 opcode (X assigned) - 1 15 DMX opcode (X_DMXChangeDesktopAttributes) - 2 2+n request length - 4 BITMASK valueMask - 4n LISTofVALUES valueList - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - DMXGetInputCount - 1 CARD8 opcode (X assigned) - 1 4 DMX opcode (X_DMXGetInputCount) - 2 1 request length - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 inputCount - 20 unused - - DMXGetInputAttributes - 1 CARD8 opcode (X assigned) - 1 5 DMX opcode (X_DMXGetInputAttributes) - 2 2 request length - 4 CARD32 deviceId - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 (n+p)/4 reply length - 4 CARD32 inputType - 4 CARD32 physicalScreen - 4 CARD32 physicalId - 4 n nameLength - 1 BOOL isCore - 1 BOOL sendsCore - 1 BOOL detached - 5 unused - n name - p pad(n) - - DMXAddInput - 1 CARD8 opcode (X assigned) - 1 16 DMX opcode (X_DMXAddInput) - 2 3+m+(n+p)/4 request length - 4 n displayNameLength - 4 CARD32 valueMask - 4m LISTofVALUES valueList - n displayName - p pad(n) - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 4 CARD32 physicalId - 16 unused - - DMXRemoveInput - 1 CARD8 opcode (X assigned) - 1 17 DMX opcode (X_DMXRemoveInput) - 2 3 request length - 4 CARD32 physicalId - ==> - 1 1 Reply - 1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 status - 20 unused - - -8. Changes to existing requests/replies/events - - No changes to existing requests, replies, or events are necessitated - by this extension. - - - -9. Acknowledgments - - - -10. References - - [X11R6.4] Robert W. Sheifler. X Window System Protocol, X Consortium - Standard, X Version 11, Release 6.4. Available from - xc/doc/specs/XProtocol and xc/doc/hardcopy/XProtocol. + + + Client-to-Server DMX Extension to the X Protocol + + $Date$, $Revision$ + + Rickard E. (Rik) Faith (faith@redhat.com) + Kevin E. Martin (kem@redhat.com) + + Copyright 2002-2004 Red Hat Inc., Raleigh, North Carolina. + + 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 on the rights to use, copy, modify, + merge, publish, distribute, sublicense, and/or sell copies of the + Software, and to permit persons to whom the Software is furnished to + do so, subject to the following conditions: + + The above copyright notice and this permission notice (including the + next paragraph) shall be included in all copies or substantial + portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS + 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. + + + +1. Overview + + The client-to-server DMX extension to the X protocol (DMX) provides + normal client applications with the ability to determine information + about the characteristics of the Xdmx server and the back-end X + servers that DMX is using. + + The name for this extension is "DMX". + + + +2. Syntactic conventions + + This document uses the same syntactic conventions requests and data + types as [X11R6.4]. + + + +3. Data types + + No new data types are defined by this extension. All data types + referenced in this document are defined in [X11R6.4]. + + + +4. Requests + + DMXQueryVersion + ==> + majorVersion: CARD32 + minorVersion: CARD32 + patchVersion: CARD32 + + Errors: None + + The protocol this extension actually supports is indicated by + majorVersion and minorVersion (patchVersion indicates the + patchlevel and is for informational purposes only). + + Any incompatible changes to the protocol should be indicated by + incrementing majorVersion. + + Small, upward-compatible changes should be indicated by incrementing + minorVersion. + + Servers that support the protocol defined in this document will + return a majorVersion of 2 and a minorVersion of 2. + + (Version 1.5 was the last version in the 1.x series; version 2.0 was + a testing version that was poorly defined.) + + + + DMXSync + ==> + status: CARD32 + + Errors: None + + This request was first supported in version 1.5 of this protocol. + The status field in the reply was introduced in version 2.0 of this + protocol. Since the status field is ignored, no changes to the + underlying protocol were required. + + This request flushes all pending protocol requests between the Xdmx + server and each back-end X server. It is used by clients that + talk directly to back-end X servers to ensure that all pending Xdmx + requests have reached all back-end servers and have been processed + by those servers. + + The value of status is always 0. + + + + DMXForceWindowCreation + window: CARD32 + ==> + status: CARD32 + + Errors: Window + + This request was first supported in version 1.2 of this protocol. + This request was changed to have a reply in version 2.0 of this + protocol. The old version of this request was deprecated and will + return BadImplementation. + + When using the lazy window creation optimization, windows are not + created on the back-end X servers until they are required. This + request forces the immediate creation of the window requested. + + The value of status is always 0. + + + + + DMXGetScreenCount + ==> + screenCount: CARD32 + + Errors: None + + This request returns the number of screens that the Xdmx server + controls. Since a DMX screen usually fills all of the available + area on a back-end server, there is usually a one-to-one + correspondence between DMX screens and backend servers. However, it + is also possible for a DMX screen to cover only part of the + available area on a back-end server, and for more than one DMX + screen to occupy different parts of the visible area on the same + back-end server. + + A DMX screen may be managed as a regular X screen in the Xdmx server + or may be joined with other DMX screens using Xinerama. + + + + DMXGetScreenAttributes + physicalScreen: CARD32 + ==> + displayName: STRING8 + logicalScreen: CARD32 + screenWindowWidth: CARD16 + screenWindowHeight: CARD16 + screenWindowXoffset: INT16 + screenWindowYoffset: INT16 + rootWindowWidth: CARD16 + rootWindowHeight: CARD16 + rootWindowXoffset: INT16 + rootWindowYoffset: INT16 + rootWindowXorigin: INT16 + rootWindowYorigin: INT16 + + Errors: Value + + This request is new in version 2.0 of this protocol. The old + DMXGetScreenInformation request is deprecated and will now return + BadImplementation. + + This request returns attributes about a single DMX screen. + + The physicalScreen value is between 0 and screenCount-1, inclusive + (values outside this range will result in a Value error). + + The displayname is the name used to open the display, either from + the Xdmx command-line or from the configuration file. + + The logicalScreen value is the value of the screen that that Xdmx + server exports to clients. When Xinerama is in use, this value is + typically 0 for all values of physicalScreen. If Xinerama is in + use, the rootWindowXOrigin and rootWindowYOrigin values specify + where the physical screen is positioned in the global Xinerama + coordinate system. Otherwise, these values are set to 0. + + The screenWindow values comprise a geometry specification (see + X(7x)) for the location of the DMX screen on the back-end screen. + The coordinant system of the back-end display is used. + + The first four rootWindow values comprise a geometry specification + (see X(7x)) for the location of the root window on the screen + window. The coordinant system of the screen window is used. In + most cases, the root window will have the same geometry as the DMX + screen window, and will occupy the same area of the back-end + display. (This would not be the case, for example, if automatic + projector alignment is used.) + + + + DMXChangeScreensAttributes + screenCount: CARD32 + maskCount: CARD32 + screens: LISTofCARD32 + valueMasks: LISTofCARD32 + valueList: LISTofVALUES + ==> + status: CARD32 + errorScreen: CARD32 + + Errors: Length, Alloc + + This request was first supported in version 2.0 of this protocol. + (A singular version of this request with the ability to change some + RootWindow attributes was supported in version 1.3 of this protocol, + has been deprecated, and will return BadImplementation.) + + This request changes the geometries and positions of the DMX screen + and DMX root windows on the back-end X servers. + + The valueMask and valueList specify which attributes are to be + changed. The possible values are: + + Attribute Type + + ScreenWindowWidth CARD16 + ScreenWindowHeight CARD16 + ScreenWindowXoffset INT16 + ScreenWindowYoffset INT16 + RootWindowWidth CARD16 + RootWindowHeight CARD16 + RootWindowXoffset INT16 + RootWindowYoffset INT16 + RootWindowXorigin INT16 + RootWindowYorigin INT16 + + The attribute values have the same meaning as do the corresponding + values for DMXGetScreenAttributes. + + Non-fatal errors will be returned in status (0 otherwise): + DmxBadXinerama: Xinerama is not active + DmxBadValue: The resulting position is not allowed + (e.g., one corner is outside the bounding box) + On error, errorScreen will contain the number of the screen that + caused the first error. + + + + DMXAddScreen + displayName: STRING8 + physicalScreen: CARD32 + valueMask: CARD32 + valueList: LISTofVALUES + ==> + status: CARD32 + physicalScreen: CARD32 + + Errors: Length, Alloc, Value + + This request was first supported in version 2.2 of this protocol. + + This request re-attaches the back-end physicalScreen to the Xdmx + server. Only back-end screens that have been previously detached + with DMXRemoveScreen may be added. The name of the back-end display + is given in displayName, and this will replace the name of the + back-end screen that was detached. Both the displayName and + physicalScreen must be correct for this request to work. + + The valueMask and valueList specify the attributes to be used. The + possible values are: + + Attribute Type + + ScreenWindowWidth CARD16 + ScreenWindowHeight CARD16 + ScreenWindowXoffset INT16 + ScreenWindowYoffset INT16 + RootWindowWidth CARD16 + RootWindowHeight CARD16 + RootWindowXoffset INT16 + RootWindowYoffset INT16 + RootWindowXorigin INT16 + RootWindowYorigin INT16 + + The attribute values have the same meaning as do the corresponding + values for DMXGetScreenAttributes. + + On success, status will be 0 and physicalScreen will contain the new + screen number. On failure, status will be non-zero. The status + will be 1 if any of the following occured: + * the -addremovescreens command-line option was not specified on + the Xdmx command line + * the value of physicalScreen is out of range + * physicalScreen has not been detached (with DMXRemoveScreen) + * displayName cannot be opened + * the visuals of displayname do not match the visuals that Xdmx + is using + * the screen data for displayName does not match the data for the + previously removed display + The status will be DmxBadValue if the attribute values are out of + range. + + + + DMXRemoveScreen + physicalScreen: CARD32 + ==> + status: CARD32 + + Errors: None + + This request was first supported in version 2.2 of this protocol. + + This request detaches the physicalScreen screen. + + On success, status will be 0. On failure, the status will 1 if any + of the following occur: + * the -addremovescreens command-line option was not specified on + the Xdmx command line + * the value of physicalScreen is out of range + * the back-end screen has already been detached. + + + + DMXGetWindowAttributes + window: CARD32 + ==> + screenCount: CARD32 + screens: LISTofCARD32 + windows: LISTofCARD32 + pos: LISTofRECTANGLE + vis: LISTofRECTANGLE + + Errors: Window, Alloc + + This request computes the return values incorrectly for version 1.0 + of this protocol. Version 1.1 of this protocol conforms to this + description. In version 2.0, the name of this request was changed + from DMXGetWindowInformation. However, since the request itself did + not change, no changes to the underlying protocol were made. + + Given a window ID on the Xdmx server, this request returns data + about how the window is represented on the back-end X servers. For + each back-end X server that displays a portion of the window, the + following information is returned: + 1) the number of the physical screen containing that portion + (which can be used with the DMXGetScreenAttributes request + to obtain more information about the screen), + 2) the window ID on the back-end X server of the window + containing that portion, + 3) the position and dimensions of the window on the back-end, in + screen coordinates, and + 4) the visible area of the window on the back-end, in + window-relative coordinates (all zeros for windows that are + not visible). + Note that DMX allows multiple back-end windows to overlap in their + view of the DMX logical window. Further, a logical window does not + have to be completely covered by back-end windows -- there may be + gaps. + + As an example, consider a 500x500 window that spans the top two + 1024x768 back-end displays (A and B) of a 2048x1536 DMX display + composed of 4 1024x768 back-end displays arranged in a cube: + A B + C D + + In this case, the DMXGetWindowAttributes call would return the + following information for the 500x500 window: + + display A: 500x500 window at 1024-250,0 (relative to back end) + with 250x500 visible at 0,0 (relative to window origin) + + display B: 500x500 window at -250,0 (relative to back end) + with 250x500 visible at 250,0 (relative to window origin) + + display C: 500x500 window at 1024-250,-768 with 0x0 visible at 0,0 + + display D: 500x500 window at -250,-768 with 0x0 visible at 0,0 + + Note that if the specified window has not yet been mapped when + DMXGetWindowAttributes is called, then a subsequent XMapWindow call + might be buffered in xlib while requests directly to the back-end X + servers are processed. This race condition can be solved by calling + DMXSync before talking directly to the back-end X servers. + + + + DMXGetDesktopAttributes + ==> + width: INT16 + height: INT16 + shiftX: INT16 + shiftY: INT16 + + Errors: None + + This request was first supported in version 2.0 of this protocol. + + This request returns the size of the bounding box of the whole + screen in width and height. The shiftX and shiftY values will + always be 0. The global bounding box is computed whether or not + Xinerama is active, and may be larger than the Xinerama screen size + because of information in the configuration file. + + + + DMXChangeDesktopAttributes + valueMask: BITMASK + valueList: LISTofVALUE + ==> + status: CARD32 + + Errors: Length, Value + + This request was first supported in version 2.0 of this protocol. + + This request resizes the bounding box of the whole screen when using + the Xinerama extension. Otherwise, it has no effect on the screen + layout. The valueMask and valueList specify which attributes are to + be changed. The possible values are: + + Attriubute Type + + Width INT16 + Height INT16 + ShiftX INT16 + ShiftY INT16 + + Width and Height specify the new width and height for the bounding + box. ShiftX and ShiftY specify where the Xinerama origin will be + placed with respect to the origin of the new bounding box. This + allows the left and upper edges of the bounding box to be changed + without changing the visual position of the windows on the desktop. + If Width or Height is not specified, the current values will be + used. If ShiftX or ShiftY is not specified, 0 will be used. + + All coordinants are in the global DMX coordinant system. If + Xinerama is not active, this request is not useful. + + Non-fatal errors will be returned in status (0 otherwise): + DmxBadXinerama: Xinerama is not active + DmxBadValue: The size of the bounding box is too large + + + + DMXGetInputCount + ==> + inputCount: CARD32 + + This request was first supported in version 1.1 of this protocol. + + This request returns the number of input devices connected to the + Xdmx server. This number is the same as that returned by + XListInputDevices, but is available even when the XInput extension + is not supported. + + + + DMXGetInputAttributes + deviceId: CARD32 + ==> + inputType: CARD32 + physicalScreen: CARD32 + physicalId: CARD32 + isCore: BOOL + sendsCore: BOOL + detached: BOOL + name: STRING8 + + Errors: Value + + This request was first supported in version 1.1 of this protocol. + In version 2.0, the name of this request was changed from + DMXGetInputInformation. However, since the request itself did not + change, no changes to the underlying protocol were made. In version + 2.2, the name of detached was changed from reservation. There was + no change in underlying protocol. + + This request returns information about the specified input device + that cannot be obtained from the XListInputDeivices call. The + deviceId is the same as that used by the XListInputDevices call, and + must be in the range 0 to inputCount-1, inclusive (values outside + this range will result in a Value error). + + The value of inputType will always be valid, and will be one of the + following values: + 0 for local (and dummy) devices, + 1 for console devices, and + 2 for back-end devices. + + For local devices, all other fields returned, except isCore and + sendsCore, are invalid. + + For console devices, the physicalScreen and physicalID will be + invalid, and the name will return the name of the X server on which + the console window is displayed. + + For back-end devices, the physicalScreen will identify the back-end + display and can be used as an argument to DMXGetScreenAttributes to + obtain more information; the physicalId will be the XInput device id + on the back-end X server; and the name will be invalid (since it + does not provide any additional information that cannot be obtained + with DMXGetScreenAttributes). + + If isCore is True, then this device is active as a true core input + device and will send core events. If sendsCore is True, then this + device is an XInput extension device, but sends core events instead + of extension events. Note that this behavior is different from that + of XFree86 or Xorg, where XInput extension devices may send both + extension events and core events. + + If detached is True, then this device has been detached and is no + longer producing input events. The device may be reattached using + DMXAddInput. + + + + DMXAddInput + displayName: STRING8 + valueMask: CARD32 + valueList: LISTofVALUES + ==> + status: CARD32 + physicalId: CARD32 + + Errors: Value, Access + + This request was first supported in version 2.2 of this protocol. + + The valueMask and valueList specify the attributes to be used. The + possible values are: + + Attribute Type + + InputType CARD32 + InputPhysicalScreen CARD32 + InputSendsCore BOOL + + This request attaches an input device to the Xdmx server. The value + of inputType will be one: + 1 for console devices, and + 2 for back-end devices. + Other values of InputType will return a BadValue error. Local + devices (inputType=0 in DMXGetInputAttributes) cannot be attached or + removed. For console devices, displayName will store the name of + the display to be used. + + For back-end devices, InputPhysicalScreen will specify the screen + number. BadValue will be returned if the screen number is out of + range. BadAccess will be returned if the input has already been + attached or if the backend screen is currently detached. + + If InputSendsCore is True, the new device will be added as a true + core device. + + If a device was removed with DMXRemoveInput an attempt will be made + to reconnect the previous devices (InputSendsCore is ignored in this + case). + + + + DMXRemoveInput + physicalId: CARD32 + ==> + status: CARD32 + + Errors: Value, Access + + This request was first supported in version 2.2 of this protocol. + + This request detaches the input device with physicalId, and all + associated inputs (e.g., if the physicalId is a backend mouse, and a + keyboard is also attached to the backend, then both devices will be + detached). If the physicalId is outside the valid range (0 to one + less than the value returned by DMXInputCount), BadValue is + returned. If the physicalId has already been detached, BadAccess is + returned. The status is always 0. + + + +5. Events + + No new events are defined by this extension. + + + +6. Errors + + No new events are defined by this extension. + + + +7. Encoding + + Deprecated DMX opcodes: + DMXGetScreenInformation 2 + DMXForceWindowCreation 6 + DMXReconfigureScreen 7 + + Valid DMX opcodes: + DMXQueryVersion 0 + DMXSync 8 + DMXForceWindowCreation 9 + + DMXGetScreenCount 1 + DMXGetScreenAttributes 10 + DMXChangeScreensAttributes 11 + DMXAddScreen 12 + DMXRemoveScreen 13 + + DMXGetWindowAttributes 3 + + DMXGetDesktopAttributes 14 + DMXChangeDesktopAttributes 15 + + DMXGetInputCount 4 + DMXGetInputAttributes 5 + DMXAddInput 16 + DMXRemoveInput 17 + + DMXQueryVersion + 1 CARD8 opcode (X assigned) + 1 0 DMX opcode (X_DMXQueryVersion) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 majorVersion + 4 CARD32 minorVersion + 4 CARD32 patchVersion + 12 unused + + DMXSync + 1 CARD8 opcode (X assigned) + 1 8 DMX opcode (X_DMXSync) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + DMXForceWindowCreation + 1 CARD8 opcode (X assigned) + 1 9 DMX opcode (X_DMXForceWindowCreation) + 2 2 request length + 4 CARD32 window + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + + DMXGetScreenCount + 1 CARD8 opcode (X assigned) + 1 1 DMX opcode (X_DMXGetScreenCount) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 screenCount + 20 unused + + DMXGetScreenAttributes + 1 CARD8 opcode (X assigned) + 1 10 DMX opcode (X_DMXGetScreenAttributes) + 2 2 request length + 4 CARD32 physicalScreen + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 1+(n+p)/4 reply length + 4 n displayNameLength + 4 CARD32 logicalScreen + 2 CARD16 screenWindowWidth + 2 CARD16 screenWindowHeight + 2 INT16 screenWindowXoffset + 2 INT16 screenWindowYoffset + 2 CARD16 rootWindowWidth + 2 CARD16 rootWindowHeight + 2 INT16 rootWindowXoffset + 2 INT16 rootWindowYoffset + 2 INT16 rootWindowXorigin + 2 INT16 rootWindowYorigin + n displayName + p pad(n) + + DMXChangeScreensAttributes + 1 CARD8 opcode (X assigned) + 1 11 DMX opcode (X_DMXChangeScreenAttributes) + 2 3+s+m+n request length + 4 s screenCount + 4 m maskCount + 4s LISTofCARD32 screens + 4m LISTofCARD32 valueMasks + 4n LISTofVALUES valueList + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 4 CARD32 errorScreen + 16 unused + + + DMXAddScreen + 1 CARD8 opcode (X assigned) + 1 12 DMX opcode (X_DMXAddScreen) + 2 3+m+(n+p)/4 request length + 4 n displayNameLength + 4 CARD32 physicalScreen + 4 CARD32 valueMask + 4m LISTofVALUES valueList + n displayName + p pad(n) + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 4 CARD32 physicalScreen + 16 unused + + DMXRemoveScreen + 1 CARD8 opcode (X assigned) + 1 13 DMX opcode (X_DMXRemoveScreen) + 2 2 request length + 4 CARD32 physicalScreen + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + DMXGetWindowAttributes + 1 CARD8 opcode (X assigned) + 1 3 DMX opcode (X_DMXGetWindowAttributes) + 2 2 request length + 4 CARD32 window + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 n*6 reply length + 4 n screenCount + 20 unused + n*4 LISTofCARD32 screens + n*4 LISTofCARD32 windows + n*8 LISTofRECTANGLE pos + n*8 LISTofRECTANGLE vis + + DMXGetDesktopAttributes + 1 CARD8 opcode (X assigned) + 1 14 DMX opcode (X_DMXGetDesktopAttributes) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 2 INT16 width + 2 INT16 height + 2 INT16 shiftX + 2 INT16 shiftY + 16 unused + + DMXChangeDesktopAttributes + 1 CARD8 opcode (X assigned) + 1 15 DMX opcode (X_DMXChangeDesktopAttributes) + 2 2+n request length + 4 BITMASK valueMask + 4n LISTofVALUES valueList + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + DMXGetInputCount + 1 CARD8 opcode (X assigned) + 1 4 DMX opcode (X_DMXGetInputCount) + 2 1 request length + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 inputCount + 20 unused + + DMXGetInputAttributes + 1 CARD8 opcode (X assigned) + 1 5 DMX opcode (X_DMXGetInputAttributes) + 2 2 request length + 4 CARD32 deviceId + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 (n+p)/4 reply length + 4 CARD32 inputType + 4 CARD32 physicalScreen + 4 CARD32 physicalId + 4 n nameLength + 1 BOOL isCore + 1 BOOL sendsCore + 1 BOOL detached + 5 unused + n name + p pad(n) + + DMXAddInput + 1 CARD8 opcode (X assigned) + 1 16 DMX opcode (X_DMXAddInput) + 2 3+m+(n+p)/4 request length + 4 n displayNameLength + 4 CARD32 valueMask + 4m LISTofVALUES valueList + n displayName + p pad(n) + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 4 CARD32 physicalId + 16 unused + + DMXRemoveInput + 1 CARD8 opcode (X assigned) + 1 17 DMX opcode (X_DMXRemoveInput) + 2 3 request length + 4 CARD32 physicalId + ==> + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 4 CARD32 status + 20 unused + + +8. Changes to existing requests/replies/events + + No changes to existing requests, replies, or events are necessitated + by this extension. + + + +9. Acknowledgments + + + +10. References + + [X11R6.4] Robert W. Sheifler. X Window System Protocol, X Consortium + Standard, X Version 11, Release 6.4. Available from + xc/doc/specs/XProtocol and xc/doc/hardcopy/XProtocol. -- cgit v1.2.3