Lines Matching +full:wake +full:- +full:on +full:- +full:motion
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
3 "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
4 <!ENTITY % xorg-defs SYSTEM "defs.ent"> %xorg-defs;
116 <revremark>Revised for X server 1.13 screen-specific devPrivates changes</revremark>
120 …ed as a reference for programmers who are implementing an X Display Server on their workstation ha…
130 …<listitem><para>"Xlib - C Language X Interface" for a view of what the client programmer sees.</pa…
134 …on your hardware, you need to know a lot about your hardware, its graphic display device(s), and (…
135 …on your machine. Some of it will require modification. Other parts may have to be completely wri…
140 <!-- Original authorship information:
142 .OF 'Porting Layer Definition'- % -'October 27, 2004'
166 -->
172 windowing system that provides high-performance, high-level,
173 device-independent graphics.
188 users can run applications on machines other than their own workstations.
191 A high-bandwidth byte stream is preferable; RS-232 at
203 For details on the byte stream protocol, see "X Window System protocol."
211 for the user on behalf of different client applications.
212 The client applications can be running on any machine on the network.
223 …<listitem><para>Device Independent (DIX) layer - code shared among all implementations</para></lis…
224 …<listitem><para>Operating System (OS) layer - code that is different for each operating system but…
225 …<listitem><para>Device Dependent (DDX) layer - code that is (potentially) different for each combi…
226 …<listitem><para>Extension Interface - a standard way to add features to the X server</para></listi…
231 actually parallel and neither one is on top of the other.
286 which are 32-bit integers that are sent over the network.
291 <title>Pre-Defined Resource Types</title>
325 <listitem><para>Attribute fields - struct fields that contain values like normal structs</para></li…
326 <listitem><para>Pointers to procedures, or structures of procedures, that operate on the object</pa…
343 <programlisting>(* pScreen->CreatePixmap)(pScreen, width, height, depth).</programlisting>
353 <programlisting>void pScreen->MyScreenRoutine(arg, arg, ...)</programlisting>
381 to clients using the X-Resource extension, to security
383 [The name argument was added in xorg-server 1.8.]
397 by class. Classes are non-exclusive subsets of the space of
441 type; the type's deleteFunc will be called on each matching resource,
513 When CallCallbacks is invoked on the list, func will be called thusly:
549 For each callback currently registered on the given callback list, call
587 identical, except the client using the extension has reversed byte-sex.
660 see if there is anything to do on the work queue; if so, it must call a DIX
724 In addition to the per-screen BlockHandlers, any module may register
749 These registered block handlers are called before the per-screen handlers:
758 which on UNIX family systems is generally represented by a struct timeval
779 The WaitForSomething on the sample server also has a built
790 before going on to the next client (see isItTimeToYield, below).
795 An implementation should return information on as
805 A list of indexes (client->index) for clients with data ready to be read or
825 private field (pClient->osPrivate), to store OS private information about the
917 The process whereby a new client-server connection starts up is
920 implementation on the sample server.
927 on his X workstation is logged onto a Cray
936 happens on your system depends upon how X and Xlib are implemented.)
939 The client application calls a TCP routine on the
942 The TCP software on the Cray does this by looking up the TCP
944 on fredsbittube.
947 All X servers on TCP listen for new clients on port 6000 by default;
948 this is known as a "well-known port" in IP terminology.
952 and checks where it came from to see if it is on the server's list
959 Each X server process running on the host machine is called a "display."
961 "corporatehydra:3.2" represents screen 2 on display 3 on
962 the multi-screened network node corporatehydra.
963 The open request would be sent on well-known port number 6003.
966 Once the byte stream is set up, what goes on does not depend very much
969 version numbers for the version of Xlib it is running, some byte-ordering information,
979 sample server implements this by keeping a timestamp for each still-connecting
986 The sample server on the distribution tape supports a simple authorization
1010 on the given byte stream to the client.
1012 the client from now on. The sample server uses the osPrivate field in
1055 You must swap the third and fourth bytes (the second 16-bit word) according to the
1056 byte-swap rules of
1059 This length is measured in 32-bit words, not in bytes. Therefore, the
1076 who->requestBuffer. This can simply be a pointer into your buffer;
1128 requested, or -1, signaling an error.
1142 the error code, having set client->errorValue to the appropriate
1162 actually ignores requests to flush output on a per-client basis
1180 You can put them all in one library file on disk.
1181 You could generate them on the fly from stroke descriptions. By placing the
1187 metadata files for them on disk (such as <filename>fonts.dir</filename>) is
1199 Memory management is based on functions in the C runtime library, malloc(),
1209 on.
1220 long-term network activity (like loading a font) before continuing with the
1241 On the other hand, if it switchs between different clients too quickly,
1250 heuristics on setting isItTimeToYield.
1254 processing on a particular client, resuming it at some later time:
1288 ClientSleep to be queued on the work queue. This does not automatically
1296 This re-enables X request processing for the specified client.
1313 argument and an implementation-dependent number of arguments following
1335 While there may be an OS-dependent driver interface between DDX
1344 Most of these routines are for graphic display on the screen or support functions thereof.
1380 The DeviceRec (Xserver/include/input.h) is a device-independent
1408 void DevicePtr->processInputProc(pEvent, device, count)
1442 <listitem><para>type - is one of the following: KeyPress, KeyRelease, ButtonPress,
1444 <listitem><para>detail - for KeyPress or KeyRelease fields, this should be the
1446 <listitem><para>time - is the time that the event happened (32-bits, in milliseconds, arbitrary ori…
1447 <listitem><para>rootX - is the x coordinate of cursor</para></listitem>
1448 <listitem><para>rootY - is the y coordinate of cursor</para></listitem>
1544 You must write four routines to do various device-specific
1552 int pInternalDevice->valuator->GetMotionProc(pdevice, coords, start, stop, pScreen)
1559 You write this DDX routine to fill in coords with all the motion
1560 events that have times (32-bit count of milliseconds) between time
1561 start and time stop. It should return the number of motion events
1562 returned. If there is no motion events support, this routine should
1570 ending points will receive a pointer-move event only as often as the
1573 a scheme to save these intermediate events in a motion buffer. A
1580 void pInternalDevice->bell->BellProc(percent, pDevice, ctrl, unknown)
1586 You need to write this routine to ring the bell on the keyboard.
1593 void pInternalDevice->somedevice->CtrlProc(device, ctrl)
1642 AutoStart should be TRUE for devices that need to be turned on at
1645 turn them on.
1676 Bool pInternalDevice->DeviceProc(device, action);
1686 DEVICE_INIT -
1691 If you return a non-zero (i.e., != Success) value from the DEVICE_INIT
1696 DEVICE_ON - If the DeviceProc is called with DEVICE_ON, then it is
1701 DEVICE_OFF - If the DeviceProc is called with DEVICE_OFF, no further
1706 DEVICE_CLOSE - At DEVICE_CLOSE (terminate or reset) time, the device should
1729 numMotionEvents is for the motion-buffer-size for the GetMotionEvents
1731 A typical length for a motion buffer would be 100 events.
1751 They describe the layout of keys on the keyboards, and the glyphs
1752 associated with them. ( See the next section for information on
1762 each key that identifies the key; the keycode-to-key mapping can be
1774 maxkeycode - minkeycode + 1.
1775 Each element of this array is a list of codes for symbols that are on that key.
1776 There is no limit to the number of symbols that can be on a key.</para></listitem>
1783 printed on each keycap. (See X11/keysym.h)
1789 TRUE if the key can be used as a modifier on the given device:
1808 Still others have high-speed graphic processors that prefer to do all of the work
1810 including maintaining their own high-level, graphic data structures.
1815 The only requirement on screens is that you be able to both read
1820 in this document on Visuals and Depths.
1823 X uses the pixel as its fundamental unit of distance on the screen.
1831 is involved in compensating for non-square pixels (a bit in the DDX
1838 server. Therefore, all the per-screen information is bundled into one data
1841 The procedure entry points in a ScreenRec operate on
1845 Windows are areas on the screen that can be drawn into by graphic
1846 routines. "Pixmaps" are off-screen graphic areas that can be drawn
1848 section on Drawables. All graphic operations work on drawables, and
1862 words, one for each pixel, using the format rules (padding and so on)
1865 All screens in a given server must agree on a set of pixmap image
1874 that has a pointer to an array of ScreenRecs, one for each screen on
1877 In addition, the screenInfo struct contains global server-wide
1878 details, such as the bit- and byte- order in all bit images, and the
1880 insists that these must be the same for all screens on the server.</para>
1894 the argc and argv from main() for your server for the command-line
1897 server command line may allow a "-D" flag followed by the name of the
1904 implementation-dependent numbers and procedures in your screenInfo,
1919 screen number of the screen installed, or -1 if there is either
1934 instance, if the screen hardware does not exist on this machine).</para>
1952 think of it as a set of pixels on the screen to be operated upon with
1957 "clipping policy," or the operations that work on regions. (The
1958 sample server uses YX-banded rectangles. Unless you have something
1981 Making direct calls is faster on many architectures.</para>
1985 RegionPtr pScreen->RegionCreate( rect, size)
1999 Your region procedures are then on their own in estimating how big the
2005 void pScreen->RegionInit (pRegion, rect, size)
2021 Bool pScreen->RegionCopy(dstrgn, srcrgn)
2028 already-created region,
2033 void pScreen->RegionDestroy( pRegion)
2043 void pScreen->RegionUninit (pRegion)
2056 Bool pScreen->Intersect(newReg, reg1, reg2)
2061 Bool pScreen->Union(newReg, reg1, reg2)
2066 Bool pScreen->Subtract(newReg, regMinuend, regSubtrahend)
2071 Bool pScreen->Inverse(newReg, pReg, pBox)
2078 The above four calls all do basic logical operations on regions. They
2097 void pScreen->RegionReset(pRegion, pBox)
2109 void pScreen->TranslateRegion(pRegion, x, y)
2121 int pScreen->RectIn(pRegion, pBox)
2135 Bool pScreen->PointInRegion(pRegion, x, y, pBox)
2154 may be too expensive. The pBox is a kind of wake-up box; DIX need not
2160 Bool pScreen->RegionNotEmpty(pRegion)
2171 void pScreen->RegionEmpty(pRegion)
2181 BoxPtr pScreen->RegionExtents(pRegion)
2194 Bool pScreen->RegionAppend (pDstRgn, pRegion)
2200 Bool pScreen->RegionValidate (pRegion, pOverlap)
2217 RegionPtr pScreen->BitmapToRegion (pPixmap)
2223 Given a depth-1 pixmap, this routine must create a valid region which
2229 RegionPtr pScreen->RectsToRegion (nrects, pRects, ordering)
2237 Given a client-supplied list of rectangles, produces a region which includes
2245 void pScreen->SendGraphicsExpose(client,pRegion,drawable,major,minor)
2263 when it strays into that window on the screen.</para>
2274 then overwriting on the source image, in the foreground color. (One
2275 bits of the source image that fall on top of zero bits of the mask
2280 but be sure to include the hot-spot.</para>
2282 CursorBits in Xserver/include/cursorstr.h is a device-independent
2283 structure containing a device-independent representation of the bits
2290 putting the cursor into off-screen memory) and set up its
2291 device-private area in either the CursorRec data structure or
2293 data structures are needed. It is more memory-conservative to share
2300 pCursor->devPriv[pScreen->myNum]
2301 pCursor->bits->devPriv[pScreen->myNum]
2311 Bool pScreen->RealizeCursor( pScr, pCurs)
2315 Bool pScreen->UnrealizeCursor( pScr, pCurs)
2325 whenever a device-independent cursor is created or destroyed. The
2328 are in Bitmap format, which may have pad bits on the right edge. You
2334 Bool pScreen->DisplayCursor( pScr, pCurs)
2339 DisplayCursor should change the cursor on the given screen to the one
2346 void pScreen->RecolorCursor( pScr, pCurs, displayed)
2362 void pScreen->ConstrainCursor( pScr, pBox)
2367 ConstrainCursor should cause the cursor to restrict its motion to the
2376 void pScreen->PointerNonInterestBox( pScr, pBox)
2382 not to report motion events while the cursor is inside a given
2383 rectangle on the given screen. It is optional and, if not
2385 the client has declared that it is not interested in motion events in
2388 motion events. This is only a hint, which may speed performance.
2393 void pScreen->CursorLimits( pScr, pCurs, pHotBox, pTopLeftBox)
2402 the device-independent cursor pCurs, and a box that DIX hypothetically
2408 Bool pScreen->SetCursorPosition( pScr, newx, newy, generateEvent)
2420 DevicePtr->processInputProc. Its effects are, of course, limited in
2433 the new screen and the new x and y coordinates of the pointer on that screen.</para>
2448 depth available on a server, there is one and only one pixmap format.
2450 padding unit. (For instance, are pixel rows padded to bytes, 16-bit
2451 words, or 32-bit words?)</para>
2463 of how the pixel values result in a color on the screen. Each visual
2468 screen it is usable on. Note that the depth does not imply the number
2473 Each visual is identified by a 32-bit visual ID which the client uses
2474 to choose what visual is desired on a given window. Clients can be
2475 using more than one visual on the same screen at the same time.</para>
2481 Pseudo - The pixel value, as a whole, is looked up
2485 True - The
2490 Gray - The pixel value is looked up in a table of length map_entries to
2501 Static Gray - The pixel value (of however many bits) determines directly the
2505 Gray Scale - The pixel value is fed through a lookup table to arrive at the level
2509 Static Color - The pixel value is fed through a fixed lookup table that yields the
2513 PseudoColor - The whole pixel value is fed through a programmable lookup
2518 True Color - Each pixel value consists of one or more bits
2522 Direct Color - Each pixel value consists of one or more bits for each primary color.
2541 each bit turns on or off one of the red, green or
2552 The display can show any 256 of 16 million colors on the screen at once.
2557 Your server software allows the user, on the
2561 From then on, the server software would not change the lookup table
2566 because he knew ahead of time he would be manipulating a lot of black-and-white
2586 A colormap is a device-independent
2587 mapping between pixel values and colors displayed on the screen.</para>
2589 Different windows on the same screen can have different
2594 Other windows may be off-color.
2608 You need to implement the following routines to handle the device-dependent
2615 Bool pScreen->CreateColormap(pColormap)
2623 section for more details on initializing colormaps.
2632 void pScreen->DestroyColormap(pColormap)
2643 void pScreen->InstallColormap(pColormap)
2648 fill a lookup table on the screen with which the colormap is associated with
2650 If there is only one hardware lookup table for the screen, then all colors on
2656 that was uninstalled may end up being off-color.
2661 void pScreen->UninstallColormap(pColormap)
2666 remove pColormap from screen pColormap->pScreen.
2680 int pScreen->ListInstalledColormaps(pScreen, pCmapList)
2693 void pScreen->StoreColors (pmap, ndef, pdefs)
2714 void pScreen->ResolveColor(pRed, pGreen, pBlue, pVisual)
2721 capable of displaying on this visual.
2738 more portable between different depth displays (a 6-bit truncated white
2739 will not look white on an 8-bit display).</para>
2761 pScreen->CreateColormap, then use can use AllocColor afterwards
2782 combination of three indices depending on the type of pmap.
2808 X supports fonts for 8-bit and 16-bit character codes (for oriental
2812 The source comes with some useful font files in an ASCII, plain-text
2813 format that should be comprehensible on a wide variety of operating
2836 convert fonts from other sources or dream up your own fonts for use on
2842 compile-time switches to convert the BDF files into a portable binary
2858 has an opportunity at font-load time
2863 a device-independent structure containing a device-independent
2871 Bool pScreen->RealizeFont(pScr, pFont)
2875 Bool pScreen->UnrealizeFont(pScr, pFont)
2890 You must supply several other screen-specific routines for
2908 void pScreen->QueryBestSize(kind, pWidth, pHeight)
2927 pScreen->SourceValidate(pDrawable, x, y, width, height)
2944 Bool pScreen->SaveScreen(pScreen, on)
2946 int on;
2954 Bool pScreen->CloseScreen(pScreen)
2962 Bool pScreen->CreateScreenResources(pScreen)
2968 request private space on all structures that support them (see
2972 all pre-allocated space requests have been registered first. With the
2981 a window on the screen or a pixmap in memory.</para>
2995 executed throughout the mi code. Size indicates the actual client-specified
3001 and continue on with more fields. Pixmaps have a single pointer field
3016 A pixmap is a three-dimensional array of bits stored somewhere offscreen,
3026 Note that the pixmap data structure is reference-counted.</para>
3038 indication of the pixmap location (host memory, off-screen, etc.). In
3047 PixmapPtr pScreen->CreatePixmap(pScreen, width, height, depth)
3065 Bool pScreen->DestroyPixmap(pPixmap)
3078 pScreen->ModifyPixmapHeader(pPixmap, width, height, depth, bitsPerPixel, devKind, pPixData)
3090 pScreen->CreatePixmap with a zero width or height to avoid
3092 pixmap data; it will be stored in an implementation-dependent place
3093 (usually pPixmap->devPrivate.ptr). This routine returns
3116 perform some operation on the data. The data should be passed in
3117 pPixData, and will be stored in an implementation-dependent place
3118 (usually pPixmap->devPrivate.ptr). The other
3129 A window is a visible, or potentially visible, rectangle on the screen.
3130 DIX windowing functions maintain an internal n-ary tree data structure, which
3135 Sibling windows constitute a doubly-linked list; the parent window has a pointer
3150 in off-screen memory; this is called "backing store".
3153 triggering an expose event and waiting for a client on the other
3157 the time to just copy already-painted sections.
3164 On the other hand, backing store can be quite complex, because
3166 to the off-screen window sections.
3173 In X, the decision to use the backing-store scheme is made
3198 that always hang on the edge of the
3213 clipList - This region, in conjunction with
3217 children included (subwindow-mode is IncludeInferiors),
3231 The device-independent portion of the server "owns" the window tree.
3241 Bool pScreen->CreateWindow(pWin)
3253 Bool pScreen->DestroyWindow(pWin);
3265 Bool pScreen->PositionWindow(pWin, x, y);
3275 The actual graphics involved in moving the pixels on the screen and drawing the
3282 Bool pScreen->RealizeWindow(pWin);
3285 Bool pScreen->UnrealizeWindow(pWin);
3301 Bool pScreen->ChangeWindowAttributes(pWin, vmask)
3307 attributes, such as the size, front-to-back ordering, title, or
3315 int pScreen->ValidateTree(pParent, pChild, kind)
3322 has a machine-independent version in Xserver/mi/mivaltree.c. This is
3327 void pScreen->PostValidateTree(pParent, pChild, kind)
3334 managing multi-layered framebuffers.
3339 void pScreen->WindowExposures(pWin, pRegion, pBSRegion)
3356 server has a machine-independent version in Xserver/mi/miexpose.c.</para>
3360 void pScreen->ClipNotify (pWin, dx, dy)
3381 void pScreen->ClearToBackground(pWin, x, y, w, h, generateExposures);
3387 This routine is called on a window in response to a ClearToBackground request
3392 on the window is incorrectly painted and needs to be repainted.
3408 void pScreen->CopyWindow(pWin, oldpt, oldRegion);
3415 pixels of a window on the screen. It should not change any other
3418 oldpt is the old location of the upper-left corner. oldRegion is the
3431 window's new region (pWin->borderClip). pWin->borderClip is gotten
3437 <title>Screen Operations for Multi-Layered Framebuffers</title>
3441 addition to the "main" planes. If you have a simple single-layer
3447 void pScreen->MarkWindow(pWin)
3453 usually a pointer to a device-dependent structure, in pWin->valdata so
3458 Bool pScreen->MarkOverlappedWindows(parent, firstChild, ppLayerWin)
3468 single-layered framebuffer case, pLayerWin == pWin.</para>
3472 Bool pScreen->ChangeSaveUnder(pLayerWin, firstChild)
3480 may turn on backing store for windows that might be covered, and may partially
3486 void pScreen->PostChangeSaveUnder(pLayerWin, firstChild)
3497 void pScreen->MoveWindow(pWin, x, y, pSib, kind)
3512 void pScreen->ResizeWindow(pWin, x, y, w, h, pSib)
3527 WindowPtr pScreen->GetLayerWindow(pWin)
3535 void pScreen->HandleExposures(pWin)
3545 void pScreen->ReparentWindow(pWin, pPriorParent)
3557 void pScreen->SetShape(pWin)
3567 void pScreen->ChangeBorderWidth(pWin, width)
3577 void pScreen->MarkUnrealizedWindow(pChild, pWin, fromConfigure)
3601 on it, whereas a graphics context describes the drawing process.
3609 operate on the GC itself and are called GC funcs. The second, called
3624 For instance, if the hardware has special support for drawing fixed-width
3626 drawing is done. It can plug into either a fixed-width procedure that makes
3627 the hardware draw characters, or a variable-width procedure that carefully
3699 GC yourself -- someone else might be using it, so a new one must
3700 be created on the fly.</para>
3726 to the GC, the device-independent state of the GC is updated.
3731 DDX may opt not to take any action at GC-modify time.
3732 This is more efficient if multiple GC-modify requests occur
3738 more of the following: 1) device private block on the GC; 2) hardware
3762 Bool pScreen->CreateGC(pGC)
3779 pGC->funcs->ChangeGC(pGC, changes)
3789 state-changes to the GC can be swallowed immediately by your graphics
3794 pGC->funcs->ValidateGC(pGC, changes, pDraw)
3804 values in the GC. It may not change the device-independent portion of
3817 more than originally intended; you should not rely on algorithms that
3820 See the Strategies document for more information on creatively using
3825 pGC->funcs->CopyGC(pGCSrc, mask, pGCDst)
3838 pGC->funcs->DestroyGC(pGC)
3861 void pGC->funcs->ChangeClip(pGC, type, pValue, nrects)
3894 void pGC->funcs->DestroyClip(pGC)
3907 void pGC->funcs->CopyClip(pgcDst, pgcSrc)
3927 to perform these on your hardware.
3944 Many server implementations will be able to use these as-is,
3950 through these low-level routines that apply pixel values rows at a time.
3959 because its destination is a protocol-style bit image.
3979 This is usually Copy, but could be any of the allowable 16 raster-ops.</para>
3997 Zero-width lines are NOT meant to be really zero width; this is the client's way
4005 algorithm, because client software assumes that every jag on every
4009 (because of their distance apart and their widths) should have such a one-pixel line
4016 whether to fill pie segments or single-edge slices of an ellipse.</para>
4041 RegionPtr pGC->ops->CopyArea(src, dst, pGC, srcx, srcy, w, h, dstx, dsty)
4054 If pGC->graphicsExposures is True, any portions of the destination which
4062 invalid area using pScreen->PaintWindowBackground.</para>
4065 windows in front of it. As text is scrolled on your window, the pixels
4067 available on the screen to copy to the right places, and so an exposure
4076 RegionPtr pGC->ops->CopyPlane(src, dst, pGC, srcx, srcy, w, h, dstx, dsty, plane)
4096 void pGC->ops->PolyPoint(dst, pGC, mode, n, pPoint)
4104 PolyPoint draws a set of one-pixel dots (foreground color)
4115 void pGC->ops->Polylines(dst, pGC, mode, n, pPoint)
4124 Zero-width lines are NOT meant to be really zero width; this is the client's way of
4135 void pGC->ops->PolySegment(dst, pGC, n, pPoint)
4150 void pGC->ops->PolyRectangle(dst, pGC, n, pRect)
4163 void pGC->ops->PolyArc(dst, pGC, n, pArc)
4178 void pGC->ops->FillPolygon(dst, pGC, shape, mode, count, pPoint)
4202 void pGC->ops->PolyFillRect(dst, pGC, n, pRect)
4216 void pGC->ops->PolyFillArc(dst, pGC, n, pArc)
4231 void pGC->ops->PutImage(dst, pGC, depth, x, y, w, h, leftPad, format, pBinImage)
4242 details on these formats). You must be able to accept all three
4252 void pScreen->GetImage(src, x, y, w, h, format, planeMask, pBinImage)
4262 according to the server-defined pixmap padding rules.
4278 void pGC->ops->ImageText8(pDraw, pGC, x, y, count, chars)
4294 int pGC->ops->PolyText8(pDraw, pGC, x, y, count, chars)
4311 int pGC->ops->PolyText16(pDraw, pGC, x, y, count, chars)
4318 void pGC->ops->ImageText16(pDraw, pGC, x, y, count, chars)
4327 except that they are for 16-bit character codes (useful
4331 looked up. The 8-bit and the 16-bit versions obviously have different
4335 CharInfo struct, lower-level software can draw the glyph desired with
4338 16-bit character fonts have a row-and-column scheme, where the 2bytes
4341 values; the CharInfo structures form a two-dimensional matrix.</para>
4346 See the X protocol specification for more details on these graphic operations.</para>
4368 The fb subsystem is a depth-independent framebuffer core, capable of
4369 operating at any depth from 1 to 32, based on the depth of the window
4370 or pixmap it is currently operating on. In particular, this means it
4371 can support pixmaps of multiple depths on the same screen. It supplies
4372 both Pixblit routines and higher-level optimized implementations of the
4379 routines, but you can use the mi routines on top of them. If you have
4386 The client, DIX, and the machine-independent routines do not carry the
4393 bottom-level clipping. For instance, the mi routines, DIX, or the
4396 the character on the edge that is partly displayed so that the Pixblit
4411 window-relative to screen-relative if desired. If you set the
4414 If it is false, then the coordinates will be passed window-relative.
4427 and windows), all of which have different requirements, on one screen.</para>
4436 glyphs. The PushPixels routine is a three-input bitblt for more
4440 machine-independent implementation that depends upon the Span
4458 void pGC->ops->FillSpans(dst, pGC, nSpans, pPoints, pWidths, sorted)
4469 based on the values in the GC.
4476 GC mode-dependent components: fgPixel (for fillStyle Solid); tile, patOrg
4482 void pGC->ops->SetSpans(pDrawable, pGC, pSrc, ppt, pWidths, nSpans, sorted)
4493 pDrawable at pPoints using the raster-op from the GC.
4512 void pScreen->GetSpans(pDrawable, wMax, pPoints, pWidths, nSpans)
4523 Each scanline returned will be server-scanline padded.
4527 GetSpans never translates -- for a window, the coordinates are already
4528 screen-relative. Consider the case of hardware that doesn't do
4530 (rectangle, polygon,. etc.) before scan-converting it, which requires
4535 scan-converted by the calling code. Contrast the behavior of
4541 simplified, both for extensions and the machine-independent core
4554 void pGC->ops->PolyGlyphBlt(pDrawable, pGC, x, y, nglyph, ppci, pglyphBase)
4565 GC mode-dependent components: fgPixel (for fillStyle Solid); tile, patOrg
4571 void pGC->ops->ImageGlyphBlt(pDrawable, pGC, x, y, nglyph, ppci, pglyphBase)
4626 void pGC->ops->PushPixels(pGC, pBitMap, pDrawable, dx, dy, xOrg, yOrg)
4635 GC mode-dependent components: fgPixel (for fillStyle Solid); tile, patOrg
4663 before terminating the server on a "clean" death. What AbortDDX() and
4680 You should write these routines to deal with device-dependent command line
4683 is not a device-dependent one, and otherwise return a count of the number
4685 option (e.g., "-realtime"), you should return the value one. This
4686 routine gets called before checks are made against device-independent
4688 device-independent argument processing. You can document the
4689 device-dependent arguments in ddxUseMsg(), which will be
4690 called from UseMsg() after printing out the device-independent arguments.</para>
4729 If the function is called more than once on the same key, all calls must use
4733 To request per-screen private space in an object, use
4739 function ensures the given <parameter>key</parameter> exists on objects of
4741 <parameter>pScreen</parameter>. The key is usable on ScreenPrivate variants
4751 function ensures only that the given <parameter>key</parameter> exists on objects of
4753 <parameter>pScreen</parameter>. Using the key on objects allocated for
4756 usable in any of the following functions. Screen-specific private storage is available
4757 only for Windows, GCs, Pixmaps and Pictures. Attempts to allocate screen-specific
4758 privates on other objects will result in a call to FatalError.
4789 If a non-zero size was given when the key was registered, or if private data
4810 There are limitations on other portions of the server implementation which
4811 make using wrappers possible; limits on when specific fields of data
4820 pre-wrapped-function-stuff ...
4822 object->functionVector = dixLookupPrivate(&object->devPrivates, privateKey);
4823 (*object->functionVector) (object, ...);
4829 dixSetPrivate(&object->devPrivates, privateKey, object->functionVector);
4830 object->functionVector = privateWrapperFunction;
4832 post-wrapped-function-stuff ...
4838 dixSetPrivate(&object->devPrivates, privateKey, object->functionVector);
4839 object->functionVector = privateWrapperFunction;
4857 function vectors, one hanging from gc->ops and the other from gc->funcs, which
4865 func wrapper, unwrap the ops and funcs, call down, and re-wrap. In each op
4867 re-wrapping you must save out the pointer you're replacing again. This way the
4914 <table frame="all" id="routines-1">
4981 <table frame="all" id="routines-2">
5048 <table frame="all" id="routines-3">