xglcomp

diff doc/fixesproto.txt @ 6:3f908f812ec7

added docs
author John Tsiombikas <nuclear@member.fsf.org>
date Fri, 29 Jan 2016 10:23:08 +0200
parents
children
line diff
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/doc/fixesproto.txt	Fri Jan 29 10:23:08 2016 +0200
     1.3 @@ -0,0 +1,577 @@
     1.4 +                        The XFIXES Extension
     1.5 +			    Version 4.0
     1.6 +			 Document Revision 2
     1.7 +			     2006-12-14
     1.8 +			    Keith Packard
     1.9 +			  keithp@keithp.com
    1.10 +
    1.11 +1. Introduction
    1.12 +
    1.13 +X applications have often needed to work around various shortcomings in the
    1.14 +core X window system.  This extension is designed to provide the minimal
    1.15 +server-side support necessary to eliminate problems caused by these
    1.16 +workarounds.
    1.17 +
    1.18 +2. Acknowledgements
    1.19 +
    1.20 +This extension is a direct result of requests made by application
    1.21 +developers, in particular,
    1.22 +
    1.23 + +	Owen Taylor for describing the issues raised with the XEMBED
    1.24 + 	mechanisms and SaveSet processing and his initial extension
    1.25 +	to handle this issue.
    1.26 +
    1.27 + +	Bill Haneman for the design for cursor image tracking.
    1.28 +
    1.29 + +	Havoc Pennington 
    1.30 +
    1.31 + +	Fredrik Höglund for cursor names
    1.32 +
    1.33 + +	Deron Johnson for cursor visibility
    1.34 +
    1.35 +3. Basic Premise
    1.36 +
    1.37 +Requests in this extension may seem to wander all over the map of X server
    1.38 +capabilities, but they are tied by a simple rule -- resolving issues raised
    1.39 +by application interaction with core protocol mechanisms that cannot be
    1.40 +adequately worked around on the client side of the wire.
    1.41 +
    1.42 +4. Extension initialization
    1.43 +
    1.44 +The client must negotiate the version of the extension before executing
    1.45 +extension requests.  Behavior of the server is undefined otherwise.
    1.46 +
    1.47 +QueryVersion
    1.48 +
    1.49 +	client-major-version:		CARD32
    1.50 +	client-minor-version:		CARD32
    1.51 +
    1.52 +	->
    1.53 +
    1.54 +	major-version:			CARD32
    1.55 +	minor-version:			CARD32
    1.56 +
    1.57 +	The client sends the highest supported version to the server and
    1.58 +	the server sends the highest version it supports, but no higher than
    1.59 +	the requested version.  Major versions changes can introduce
    1.60 +	new requests, minor version changes introduce only adjustments to
    1.61 +	existing requests or backward compatible changes.  It is
    1.62 +	the clients responsibility to ensure that the server supports
    1.63 +	a version which is compatible with its expectations.
    1.64 +
    1.65 +************* XFIXES VERSION 1 OR BETTER ***********
    1.66 +
    1.67 +5. Save Set processing changes
    1.68 +
    1.69 +Embedding one application within another provides a way of unifying
    1.70 +disparate documents and views within a single framework.  From the X
    1.71 +protocol perspective, this appears similar to nested window managers; the
    1.72 +embedding application "manages" the embedded windows much as a window
    1.73 +manager does for top-level windows.  To protect the embedded application
    1.74 +from embedding application failure, it is reasonable to use the core SaveSet
    1.75 +mechanism so that embedding application failure causes embedded windows to
    1.76 +be preserved instead of destroyed.
    1.77 +
    1.78 +The core save set mechanism defines the target for each save set member
    1.79 +window as the nearest enclosing window not owned by the terminating client.
    1.80 +For embedding applications, this nearest window is usually the window
    1.81 +manager frame.  The problem here is that the window manager will not
    1.82 +generally expect to receive and correctly manage new windows appearing within
    1.83 +that window by the save set mechanism, and will instead destroy the frame
    1.84 +window in response to the client window destruction.  This causes the
    1.85 +embedded window to be destroyed.
    1.86 +
    1.87 +An easy fix for this problem is to change the target of the save set member
    1.88 +to a window which won't be affected by the underlying window destruction.
    1.89 +XFIXES chooses the root window as the target.
    1.90 +
    1.91 +Having embedded windows suddenly appear at the top level can confuse users,
    1.92 +so XFIXES also lets the client select whether the window should end up
    1.93 +unmapped after the save set processing instead of unconditionally making
    1.94 +them be mapped.
    1.95 +
    1.96 +5.1 Requests
    1.97 +
    1.98 +ChangeSaveSet
    1.99 +
   1.100 +		window:				Window
   1.101 +		mode:				{ Insert, Delete }
   1.102 +		target:				{ Nearest, Root }
   1.103 +		map:				{ Map, Unmap }
   1.104 +
   1.105 +	ChangeSaveSet is an extension of the core protocol ChangeSaveSet
   1.106 +	request.  As in that request, mode specifies whether the indicated
   1.107 +	window is inserted or deleted from the save-set.  Target specifies
   1.108 +	whether the window is reparented to the nearest non-client window as
   1.109 +	in the core protocol, or reparented to the root window.  Map
   1.110 +	specifies whether the window is mapped as in the core protocol or
   1.111 +	unmapped.
   1.112 +
   1.113 +6. Selection Tracking
   1.114 +
   1.115 +Applications wishing to monitor the contents of current selections must
   1.116 +poll for selection changes.  XFIXES improves this by providing an event
   1.117 +delivered whenever the selection ownership changes.
   1.118 +
   1.119 +6.1 Types
   1.120 +
   1.121 +	SELECTIONEVENT			{ SetSelectionOwner,
   1.122 +					  SelectionWindowDestroy,
   1.123 +					  SelectionClientClose }
   1.124 +
   1.125 +6.1 Events
   1.126 +
   1.127 +SelectionNotify
   1.128 +
   1.129 +	subtype:			SELECTIONEVENT
   1.130 +	window:				Window
   1.131 +	owner:				Window
   1.132 +	selection:			Atom
   1.133 +	timestamp:			Timestamp
   1.134 +	selection-timestamp:		Timestamp
   1.135 +
   1.136 +6.2 Requests
   1.137 +
   1.138 +SelectSelectionInput
   1.139 +
   1.140 +		window:				Window
   1.141 +		selection:			Atom
   1.142 +		event-mask:			SETofSELECTIONEVENT
   1.143 +
   1.144 +	Selects for events to be delivered to window when various causes of
   1.145 +	ownership of selection occur.  Subtype indicates the cause of the
   1.146 +	selection ownership change.  Owner is set to the current selection
   1.147 +	owner, or None.  Timestamp indicates the time the event was
   1.148 +	generated while selection-timestamp indicates the timestamp used to
   1.149 +	own the selection.
   1.150 +
   1.151 +7. Cursor Image Monitoring
   1.152 +
   1.153 +Mirroring the screen contents is easily done with the core protocol or VNC
   1.154 +addons, except for the current cursor image.  There is no way using the core
   1.155 +protocol to discover which cursor image is currently displayed.  The
   1.156 +cursor image often contains significant semantic content about the user
   1.157 +interface.  XFIXES provides a simple mechanism to discover when the cursor
   1.158 +image changes and to fetch the current cursor image.
   1.159 +
   1.160 +As the current cursor may or may not have any XID associated with it, there
   1.161 +is no stable name available.  Instead, XFIXES returns only the image of the
   1.162 +current cursor and provides a way to identify cursor images to avoid
   1.163 +refetching the image each time it changes to a previously seen cursor.
   1.164 +
   1.165 +7.1 Types
   1.166 +	CURSOREVENT			{ DisplayCursor }
   1.167 +
   1.168 +7.2 Events
   1.169 +
   1.170 +CursorNotify
   1.171 +
   1.172 +	subtype:		CURSOREVENT
   1.173 +	window:			Window
   1.174 +	cursor-serial:		CARD32
   1.175 +	timestamp:		Timestamp
   1.176 +	name:			Atom		(Version 2 only)
   1.177 +
   1.178 +7.3 Requests
   1.179 +
   1.180 +SelectCursorInput
   1.181 +
   1.182 +		window:			Window
   1.183 +		event-mask:		SETofCURSOREVENT
   1.184 +
   1.185 +	This request directs cursor change events to the named window.
   1.186 +	Events will be delivered irrespective of the screen on which they
   1.187 +	occur.  Subtype indicates the cause of the cursor image change
   1.188 +	(there is only one subtype at present).  Cursor-serial is a number
   1.189 +	assigned to the cursor image which identifies the image.  Cursors
   1.190 +	with different serial numbers may have different images.  Timestamp
   1.191 +	is the time of the cursor change.
   1.192 +
   1.193 +	Servers supporting the X Input Extension Version 2.0 or higher only
   1.194 +	notify the clients of cursor change events for the ClientPointer, not
   1.195 +	of any other master pointer (see Section 4.4. in the XI2 protocol
   1.196 +	specificiation).
   1.197 +
   1.198 +GetCursorImage
   1.199 +
   1.200 +		->
   1.201 +
   1.202 +		x:			INT16
   1.203 +		y:			INT16
   1.204 +		width:			CARD16
   1.205 +		height:			CARD16
   1.206 +		x-hot:			CARD16
   1.207 +		y-hot:			CARD16
   1.208 +		cursor-serial:		CARD32
   1.209 +		cursor-image:		LISTofCARD32
   1.210 +
   1.211 +	GetCursorImage returns the image of the current cursor.  X and y are
   1.212 +	the current cursor position.  Width and height are the size of the
   1.213 +	cursor image.  X-hot and y-hot mark the hotspot within the cursor
   1.214 +	image.  Cursor-serial provides the number assigned to this cursor
   1.215 +	image, this same serial number will be reported in a CursorNotify
   1.216 +	event if this cursor image is redisplayed in the future.
   1.217 +
   1.218 +	The cursor image itself is returned as a single image at 32 bits per
   1.219 +	pixel with 8 bits of alpha in the most significant 8 bits of the
   1.220 +	pixel followed by 8 bits each of red, green and finally 8 bits of
   1.221 +	blue in the least significant 8 bits.  The color components are
   1.222 +	pre-multiplied with the alpha component.
   1.223 +	
   1.224 +************* XFIXES VERSION 2 OR BETTER ***********
   1.225 +
   1.226 +8. Region Objects
   1.227 +
   1.228 +The core protocol doesn't expose regions as a primitive object and this
   1.229 +makes many operations more complicated than they really need to be.  Adding
   1.230 +region objects simplifies expose handling, the Shape extension and other
   1.231 +operations. These operations are also designed to support a separate
   1.232 +extension, the X Damage Extension.
   1.233 +
   1.234 +8.1 Types
   1.235 +
   1.236 +	Region:				XID
   1.237 +	WINDOW_REGION_KIND:		{ Bounding, Clip }
   1.238 +	
   1.239 +8.2 Errors
   1.240 +
   1.241 +	Region				The specified region is invalid
   1.242 +
   1.243 +8.3 Requests
   1.244 +
   1.245 +CreateRegion
   1.246 +
   1.247 +		region:				REGION
   1.248 +		rects:				LISTofRECTANGLE
   1.249 +
   1.250 +	Creates a region initialized to the specified list of rectangles.
   1.251 +	The rectangles may be specified in any order, their union becomes
   1.252 +	the region.  The core protocol allows applications to specify an
   1.253 +	order for the rectangles, but it turns out to be just as hard to
   1.254 +	verify the rectangles are actually in that order as it is to simply
   1.255 +	ignore the ordering information and union them together.  Hence,
   1.256 +	this request dispenses with the ordering information.
   1.257 +
   1.258 +	Errors: IDChoice
   1.259 +
   1.260 +CreateRegionFromBitmap
   1.261 +
   1.262 +		region:				REGION
   1.263 +		bitmap:				PIXMAP
   1.264 +
   1.265 +	Creates a region initialized to the set of 'one' pixels in bitmap
   1.266 +	(which must be depth 1, else Match error).
   1.267 +
   1.268 +	Errors: Pixmap, IDChoice, Match
   1.269 +
   1.270 +CreateRegionFromWindow
   1.271 +
   1.272 +		window:				Window
   1.273 +		kind:				WINDOW_REGION_KIND
   1.274 +		region:				Region
   1.275 +
   1.276 +	Creates a region initialized to the specified window region.  See the
   1.277 +	Shape extension for the definition of Bounding and Clip regions.
   1.278 +
   1.279 +	Errors: Window, IDChoice, Value
   1.280 +
   1.281 +CreateRegionFromGC
   1.282 +
   1.283 +		gc:				GContext
   1.284 +		region:				Region
   1.285 +
   1.286 +	Creates a region initialized from the clip list of the specified
   1.287 +	GContext.
   1.288 +
   1.289 +	Errors: GContext, IDChoice
   1.290 +
   1.291 +CreateRegionFromPicture
   1.292 +
   1.293 +		picture:			Picture
   1.294 +		region:				Region
   1.295 +
   1.296 +
   1.297 +	Creates a region initialized from the clip list of the specified
   1.298 +	Picture.
   1.299 +
   1.300 +	Errors: Picture, IDChoice
   1.301 +
   1.302 +DestroyRegion
   1.303 +
   1.304 +		region:				Region
   1.305 +
   1.306 +	Destroys the specified region.
   1.307 +
   1.308 +	Errors: Region
   1.309 +
   1.310 +SetRegion
   1.311 +
   1.312 +		region:				Region
   1.313 +		rects:				LISTofRECTANGLE
   1.314 +
   1.315 +	This replaces the current contents of region with the region formed
   1.316 +	by the union of rects.
   1.317 +
   1.318 +CopyRegion
   1.319 +		source:				Region
   1.320 +		destination:			Region
   1.321 +
   1.322 +	This replaces the contents of destination with the contents of 
   1.323 +	source.
   1.324 +
   1.325 +UnionRegion
   1.326 +IntersectRegion
   1.327 +SubtractRegion
   1.328 +
   1.329 +		source1:			Region
   1.330 +		source2:			Region
   1.331 +		destination:			Region
   1.332 +	
   1.333 +	Combines source1 and source2, placing the result in destination.
   1.334 +	Destination may be the same as either source1 or source2.
   1.335 +
   1.336 +	Errors: Region, Value
   1.337 +	
   1.338 +InvertRegion
   1.339 +
   1.340 +		source:				Region
   1.341 +		bounds:				RECTANGLE
   1.342 +		destination:			Region
   1.343 +	
   1.344 +	The source region is subtracted from the region specified by
   1.345 +	bounds.  The result is placed in destination, replacing its contents.
   1.346 +
   1.347 +	Errors: Region
   1.348 +	
   1.349 +TranslateRegion
   1.350 +
   1.351 +		region:				Region
   1.352 +		dx, dy:				INT16
   1.353 +
   1.354 +	The region is translated by dx, dy in place.
   1.355 +
   1.356 +	Errors: Region
   1.357 +
   1.358 +RegionExtents
   1.359 +
   1.360 +		source:				Region
   1.361 +		destination:			Region
   1.362 +
   1.363 +	The extents of the source region are placed in the destination
   1.364 +
   1.365 +FetchRegion
   1.366 +
   1.367 +		region:				Region
   1.368 +		->
   1.369 +		extents:			RECTANGLE
   1.370 +		rectangles:			LISTofRECTANGLE
   1.371 +
   1.372 +	The region is returned as a list of rectangles in YX-banded order.
   1.373 +
   1.374 +	Errors: Region
   1.375 +
   1.376 +SetGCClipRegion
   1.377 +
   1.378 +		gc:				GCONTEXT
   1.379 +		clip-x-origin, clip-y-origin:	INT16
   1.380 +		region:				Region or None
   1.381 +
   1.382 +	This request changes clip-mask in gc to the specified region and
   1.383 +	sets the clip origin.  Output will be clipped to remain contained
   1.384 +	within the region.  The clip origin is interpreted relative to the
   1.385 +	origin of whatever destination drawable is specified in a graphics
   1.386 +	request.  The region is interpreted relative to the clip origin.
   1.387 +	Future changes to region have no effect on the gc clip-mask.
   1.388 +
   1.389 +	Errors: GContext, Region
   1.390 +
   1.391 +SetWindowShapeRegion
   1.392 +
   1.393 +		dest:				Window
   1.394 +		destKind:			SHAPE_KIND
   1.395 +		xOff, yOff:			INT16
   1.396 +		region:				Region or None
   1.397 +
   1.398 +	This request sets the specified (by destKind) Shape extension region
   1.399 +	of the window to region, offset by xOff and yOff.   Future changes to
   1.400 +	region have no effect on the window shape.
   1.401 +
   1.402 +	Errors: Window, Value, Region
   1.403 +
   1.404 +SetPictureClipRegion
   1.405 +
   1.406 +		picture:			Picture
   1.407 +		clip-x-origin, clip-y-origin:	INT16
   1.408 +		region:				Region or None
   1.409 +
   1.410 +	This request changes clip-mask in picture to the specified region
   1.411 +	and sets the clip origin.  Input and output will be clipped to
   1.412 +	remain contained within the region.  The clip origin is interpreted
   1.413 +	relative to the origin of the drawable associated with picture.  The
   1.414 +	region is interpreted relative to the clip origin.  Future changes
   1.415 +	to region have no effect on the picture clip-mask.
   1.416 +
   1.417 +	Errors: Picture, Region
   1.418 +
   1.419 +9. Cursor Names
   1.420 +
   1.421 +Attaching names to cursors permits some abstract semantic content to be
   1.422 +associated with specific cursor images.  Reflecting those names back to
   1.423 +applications allows that semantic content to be related to the user through
   1.424 +non-visual means.
   1.425 +
   1.426 +9.1 Events
   1.427 +
   1.428 +CursorNotify
   1.429 +
   1.430 +		subtype:		CURSOREVENT
   1.431 +		window:			Window
   1.432 +		cursor-serial:		CARD32
   1.433 +		timestamp:		Timestamp
   1.434 +		name:			Atom or None
   1.435 +	
   1.436 +	In Version 2 of the XFIXES protocol, this event adds the atom
   1.437 +	of any name associated with the current cursor (else None).
   1.438 +
   1.439 +9.2 Requests
   1.440 +
   1.441 +SetCursorName
   1.442 +
   1.443 +		cursor:			CURSOR
   1.444 +		name:			LISTofCARD8
   1.445 +
   1.446 +	This request interns name as an atom and sets that atom as the name
   1.447 +	of cursor.
   1.448 +
   1.449 +	Errors: Cursor
   1.450 +
   1.451 +GetCursorName
   1.452 +
   1.453 +		cursor:			CURSOR
   1.454 +		->
   1.455 +		atom:			ATOM or None
   1.456 +		name:			LISTofCARD8
   1.457 +
   1.458 +	This request returns the name and atom of cursor.  If no name is
   1.459 +	set, atom is None and name is empty.
   1.460 +
   1.461 +	Errors: Cursor
   1.462 +
   1.463 +GetCursorImageAndName
   1.464 +
   1.465 +		->
   1.466 +
   1.467 +		x:			INT16
   1.468 +		y:			INT16
   1.469 +		width:			CARD16
   1.470 +		height:			CARD16
   1.471 +		x-hot:			CARD16
   1.472 +		y-hot:			CARD16
   1.473 +		cursor-serial:		CARD32
   1.474 +		cursor-atom:		ATOM
   1.475 +		cursor-name:		LISTofCARD8
   1.476 +		cursor-image:		LISTofCARD32
   1.477 +
   1.478 +	This is similar to GetCursorImage except for including both
   1.479 +	the atom and name of the current cursor.
   1.480 +
   1.481 +ChangeCursor
   1.482 +
   1.483 +		source, destination:	CURSOR
   1.484 +
   1.485 +	This request replaces all references to the destination with a
   1.486 +	reference to source.  Any existing uses of the destination cursor
   1.487 +	object will now show the source cursor image.
   1.488 +
   1.489 +ChangeCursorByName
   1.490 +
   1.491 +		src:			CURSOR
   1.492 +		name:			LISTofCARD8
   1.493 +
   1.494 +	This request replaces the contents of all cursors with the specified
   1.495 +	name with the src cursor.
   1.496 +
   1.497 +************* XFIXES VERSION 3 OR BETTER ***********
   1.498 +
   1.499 +10. Region Expansion
   1.500 +
   1.501 +This update provides another operation on the region objects defined in
   1.502 +Section 8 of this document.
   1.503 +
   1.504 +10.1 Requests
   1.505 +
   1.506 +ExpandRegion
   1.507 +		source:				REGION
   1.508 +		destination:			REGION
   1.509 +		left, right, top, bottom:	CARD16
   1.510 +
   1.511 +	Creates destination region containing the area specified by
   1.512 +	expanding each rectangle in the source region by the specified
   1.513 +	number of pixels to the left, right, top and bottom.
   1.514 +
   1.515 +************* XFIXES VERSION 4 OR BETTER ***********
   1.516 +
   1.517 +11. Cursor Visibility
   1.518 +
   1.519 +Composite managers may want to render the cursor themselves instead of
   1.520 +relying on the X server sprite drawing, this provides a way for them to
   1.521 +do so without getting a double cursor image.
   1.522 +
   1.523 +11.1 Requests
   1.524 +
   1.525 +HideCursor
   1.526 +
   1.527 +		window:			WINDOW
   1.528 +
   1.529 +	A client sends this request to indicate that it wants the
   1.530 +	cursor image to be hidden (i.e. to not be displayed) when
   1.531 +	the sprite is inside the specified window, or one of its
   1.532 +	subwindows. If the sprite is inside a window for which one
   1.533 +	or more active clients have requested cursor hiding then the
   1.534 +	cursor image will not be displayed.
   1.535 +
   1.536 +	Note that even though cursor hiding causes the cursor image
   1.537 +	to be invisible, CursorNotify events will still be sent
   1.538 +	normally, as if the cursor image were visible.
   1.539 +
   1.540 +	If, during a grab, one or more active clients have requested
   1.541 +	cursor hiding for grab window, or one of its ancestors, the
   1.542 +	cursor image of the grab cursor will not be displayed during
   1.543 +	the lifetime of that grab.
   1.544 +
   1.545 +	When a client with outstanding cursor hiding requests
   1.546 +	terminates its connection these requests will be deleted.
   1.547 +
   1.548 +	Servers supporting the X Input Extension Version 2.0 or higher hide
   1.549 +	all visible cursors in response to a HideCursor request. If a master
   1.550 +	pointer is created while the cursors are hidden, this master pointer's
   1.551 +	cursor will be hidden as well.
   1.552 +
   1.553 +ShowCursor
   1.554 +
   1.555 +		window:			WINDOW
   1.556 +
   1.557 +	A client sends this request to indicate that it wants the
   1.558 +	cursor image to be displayed when the sprite is inside the
   1.559 +	specified window, or one of its subwindows. If the sprite
   1.560 +	is inside a window for which no active clients have requested
   1.561 +	cursor hiding then the cursor image for that window will be
   1.562 +	displayed. In other words, if a client calls HideCursor for
   1.563 +	a specified window, or window subtree, this request reverses
   1.564 +	the effects of the HideCursor request.
   1.565 +
   1.566 +	If the client has made no outstanding HideCursor requests
   1.567 +	a BadMatch error is generated.
   1.568 +
   1.569 +	Servers supporting the X Input Extension Version 2.0 or higher show
   1.570 +	all visible cursors in response to a ShowCursor request.
   1.571 +
   1.572 +99. Future compatibility
   1.573 +
   1.574 +This extension is not expected to remain fixed.  Future changes will
   1.575 +strive to remain compatible if at all possible.  The X server will always
   1.576 +support version 1 of the extension protocol if requested by a client.
   1.577 +
   1.578 +Additions to the protocol will always by marked by minor version number
   1.579 +changes so that applications will be able to detect what requests are
   1.580 +supported.