3 Client-to-Server DMX Extension to the X Protocol
7 Rickard E. (Rik) Faith (faith@redhat.com)
8 Kevin E. Martin (kem@redhat.com)
10 Copyright 2002,2003 Red Hat Inc., Raleigh, North Carolina.
12 Permission is hereby granted, free of charge, to any person
13 obtaining a copy of this software and associated documentation files
14 (the "Software"), to deal in the Software without restriction,
15 including without limitation on the rights to use, copy, modify,
16 merge, publish, distribute, sublicense, and/or sell copies of the
17 Software, and to permit persons to whom the Software is furnished to
18 do so, subject to the following conditions:
20 The above copyright notice and this permission notice (including the
21 next paragraph) shall be included in all copies or substantial
22 portions of the Software.
24 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
25 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
26 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
27 NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS
28 BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
29 ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
30 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
37 The client-to-server DMX extension to the X protocol (DMX) provides
38 normal client applications with the ability to determine information
39 about the characteristics of the Xdmx server and the back-end X
40 servers that DMX is using.
42 The name for this extension is "DMX".
46 2. Syntactic conventions
48 This document uses the same syntactic conventions requests and data
55 No new data types are defined by this extension. All data types
56 referenced in this document are defined in [X11R6.4].
68 The protocol this extension actually supports is indicated by
69 majorVersion and minorVersion (patchVersion indicates the
70 patchlevel and is for informational purposes only).
72 Any incompatible changes to the protocol should be indicated by
73 incrementing majorVersion.
75 Small, upward-compatible changes should be indicated by incrementing
78 Servers that support the protocol defined in this document will
79 return a majorVersion of 1 and a minorVersion of 1.
87 This request returns the number of back-end screens that the Xdmx
88 server controls. A back-end screen may be managed as a regular X
89 screen in the Xdmx server or may be joined with other back-end
90 screens using Xinerama. (The information returned by this request
91 does not change while Xdmx is running and may be cached on the
96 DMXGetScreenInformation
97 physicalScreen: CARD32
104 logicalScreen: CARD32
110 This request returns information about individual back-end screens.
111 The physicalScreen value is between 0 and screenCount-1, inclusive
112 (values outside this range will result in a Value error). The
113 displayname is the name used to open the display, either from the
114 Xdmx command-line or from the configuration file. The width,
115 height, xoffset, and yoffset values comprise a geometry
116 specification (see X(7x)) for the location of the DMX window on the
117 back-end screen. This request will always return non-negative
118 (i.e., normalized) values for xoffset and yoffset. The
119 logicalScreen value is the value of the screen that that Xdmx server
120 exports to clients. When Xinerama is in use, this value is
121 typically 0 for all values of physicalScreen. If Xinerama is in
122 use, the xorigin and yorigin values specify where the physical
123 screen is positioned in the global Xinerama coordinate system.
124 Otherwise, these values are set to 0. (The information returned by
125 this request does not change while Xdmx is running and may be cached
130 DMXGetWindowInformation
134 screens: LISTofCARD32
135 windows: LISTofCARD32
139 Errors: Window, Alloc
141 This request computed the return values incorrectly for version 1.0
142 of this protocol. Version 1.1 of this protocol conforms to this
145 Given a window ID on the Xdmx server, this request returns data
146 about how the window is represented on the back-end X servers. For
147 each back-end X server that displays a portion of the window, the
148 following information is returned:
149 1) the number of the physical screen containing that portion
150 (which can be used with the DMXGetScreenInformation request
151 to obtain more information about the screen),
152 2) the window ID on the back-end X server of the window
153 containing that portion,
154 3) the position and dimensions of the window on the back-end, in
155 screen coordinates, and
156 4) the visible area of the window on the back-end, in
157 window-relative coordinates (all zeros for windows that are
159 Note that DMX allows multiple back-end windows to overlap in their
160 view of the DMX logical window. Further, a logical window does not
161 have to be completely covered by back-end windows -- there may be
164 As an example, consider a 500x500 window that spans the top two
165 1024x768 back-end displays (A and B) of a 2048x1536 DMX display
166 composed of 4 1024x768 back-end displays arranged in a cube:
170 In this case, the DMXGetWindowInformation call would return the
171 following information for the 500x500 window:
173 display A: 500x500 window at 1024-250,0 (relative to back end)
174 with 250x500 visible at 0,0 (relative to window origin)
176 display B: 500x500 window at -250,0 (relative to back end)
177 with 250x500 visible at 250,0 (relative to window origin)
179 display C: 500x500 window at 1024-250,-768 with 0x0 visible at 0,0
181 display D: 500x500 window at -250,-768 with 0x0 visible at 0,0
183 Note that if the specified window has not yet been mapped when
184 DMXGetWindowInformation is called, then a subsequent XMapWindow call
185 might be buffered in xlib while requests directly to the back-end X
186 servers are processed. This race condition can be solved by calling
187 DMXSync before talking directly to the back-end X servers.
194 This request was first supported in version 1.1 of this protocol.
196 This request returns the number of input devices connected to the
197 Xdmx server. This number is the same as that returned by
198 XListInputDevices, but is available even when the XInput extension
203 DMXGetInputInformation
207 physicalScreen: CARD32
215 This request was first supported in version 1.1 of this protocol.
217 This request returns information about the specified input device
218 that cannot be obtained from the XListInputDeivices call. The
219 deviceId is the same as that used by the XListInputDevices call, and
220 must be in the range 0 to inputCount-1, inclusive (values outside
221 this range will result in a Value error).
223 The value of inputType will always be value, and will be one of the
225 0 for local (and dummy) devices,
226 1 for console devices, and
227 2 for back-end devices.
229 For local devices, all other fields returned, except isCore and
230 sendsCore, are invalid.
232 For console devices, the physicalScreen and physicalID will be
233 invalid, and the name will return the name of the X server on which
234 the console window is displayed.
236 For back-end devices, the physicalScreen will identify the back-end
237 display and can be used as an argument to DMXGetScreenInformation to
238 obtain more information; the physicalId will be the XInput device id
239 on the back-end X server; and the name will be invalid (since it
240 does not provide any additional information that cannot be obtained
241 with DMXGetScreenInformation).
243 If isCore is True, then this device is active as a true core input
244 device and will send core events. If sendsCore is True, then this
245 device queried an XInput extension device, but sends core events
246 instead of extension events. Note that this behavior is different
247 from that of XFree86, where XInput extension devices may send both
248 extension events and core events.
252 DMXForceWindowCreation
258 This request was first supported in version 1.2 of this protocol.
260 When using the lazy window creation optimization, windows are not
261 created on the back-end X servers until they are required. This
262 request forces the immediate creation of the window requested.
275 This request was first supported in version 1.3 of this protocol.
277 This request reconfigures the screen position to coordinates (x,y)
278 when using the Xinerama extension. Otherwise, it is a NOP. Illegal
279 values for screen will result in a BadValue error. Other non-fatal
280 errors will be returned in status.
287 This request was first supported in version 1.5 of this protocol.
289 This request flushes all pending protocol requests between the Xdmx
290 server and each back-end X server. It is used by a client that
291 talks directly to back-end X servers
293 To ensure proper synchronization semantics, this request has a
294 reply, but the reply does not carry any information.
300 No new events are defined by this extension.
306 No new events are defined by this extension.
313 1 CARD8 opcode (X assigned)
314 1 0 DMX opcode (X_DMXQueryVersion)
319 2 CARD16 sequence number
321 4 CARD32 majorVersion
322 4 CARD32 minorVersion
323 4 CARD32 patchVersion
327 1 CARD8 opcode (X assigned)
328 1 1 DMX opcode (X_DMXGetScreenCount)
333 2 CARD16 sequence number
338 DMXGetScreenInformation
339 1 CARD8 opcode (X assigned)
340 1 2 DMX opcode (X_DMXGetScreenInformation)
342 4 CARD32 physicalScreen
346 2 CARD16 sequence number
348 4 n displayNameLength
353 4 CARD32 logicalScreen
360 DMXGetWindowInformation
361 1 CARD8 opcode (X assigned)
362 1 3 DMX opcode (X_DMXGetWindowInformation)
368 2 CARD16 sequence number
372 n*4 LISTofCARD32 screens
373 n*4 LISTofCARD32 windows
374 n*8 LISTofRECTANGLE pos
375 n*8 LISTofRECTANGLE vis
378 1 CARD8 opcode (X assigned)
379 1 DMX opcode (X_DMXGetInputCount)
384 2 CARD16 sequence number
389 DMXGetInputInformation
390 1 CARD8 opcode (X assigned)
391 1 4 DMX opcode (X_DMXGetInputInformation)
397 2 CARD16 sequence number
400 4 CARD32 physicalScreen
409 DMXForceWindowCreation
410 1 CARD8 opcode (X assigned)
411 1 2 DMX opcode (X_DMXForceWindowCreation)
417 1 CARD8 opcode (X assigned)
418 1 2 DMX opcode (X_DMXReconfigureScreen)
426 2 CARD16 sequence number
432 1 CARD8 opcode (X assigned)
433 1 0 DMX opcode (X_DMXSync)
438 2 CARD16 sequence number
443 8. Changes to existing requests/replies/events
445 No changes to existing requests, replies, or events are necessitated
456 [X11R6.4] Robert W. Sheifler. X Window System Protocol, X Consortium
457 Standard, X Version 11, Release 6.4. Available from
458 xc/doc/specs/XProtocol and xc/doc/hardcopy/XProtocol.