aboutsummaryrefslogtreecommitdiff
path: root/xorg-server/hw/dmx/doc
diff options
context:
space:
mode:
Diffstat (limited to 'xorg-server/hw/dmx/doc')
-rw-r--r--xorg-server/hw/dmx/doc/DMXSpec-v1.txt916
-rw-r--r--xorg-server/hw/dmx/doc/DMXSpec.txt1750
2 files changed, 1333 insertions, 1333 deletions
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.