.Ï . *Ï .. /Ï èCVS /Ï . .Ï .. 0Ï
Repository yÍ ÔEntries uÍ Ä Entries.Log yÍ °Entries.Backup 1.1.1.1.0.4
xf-3_0b:1.1.1.1
xf-3_0a:1.1.1.1
xf-3_0:1.1.1.1
XC:1.1.1.1.0.2
X11R6_0:1.1.1.1
X11R6:1.1.1;
locks; strict;
comment @# @;
1.2
date 2003.05.27.17.58.26; author tsi; state Exp;
branches;
next 1.1;
1.1
date 94.04.27.07.13.15; author dawes; state Exp;
branches
1.1.1.1;
next ;
1.1.1.1
date 94.04.27.07.13.16; author dawes; state Exp;
branches;
next 1.1.1.2;
1.1.1.2
date 2001.01.16.23.02.11; author dawes; state Exp;
branches;
next ;
desc
@@
1.2
log
@ 192. Do not unnecessarily link libXmu, libXt and/or libXext into executables
(Marc La France).
@
text
@XCOMM $Xorg: Imakefile,v 1.3 2000/08/17 19:54:56 cpqbld Exp $
XCOMM $XFree86$
DEPLIBS = $(DEPXONLYLIB)
LOCAL_LIBRARIES = $(XONLYLIB)
SimpleProgramTarget(xrefresh)
@
1.1
log
@Initial revision
@
text
@d1 8
a8 3
XCOMM $XConsortium: Imakefile,v 1.6 91/07/17 16:07:01 gildea Exp $
DEPLIBS = $(DEPXLIB)
LOCAL_LIBRARIES = $(XLIB)
@
1.1.1.1
log
@X11R6 Public Patch 0
@
text
@@
1.1.1.2
log
@X11R6.5.1
@
text
@d1 1
a1 1
XCOMM $Xorg: Imakefile,v 1.3 2000/08/17 19:54:56 cpqbld Exp $
@
> * Optional.
> */
> void ScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area);
Where is "ScratchSave" from?
>
> [Necessary structure description here.]
>
> EXA driver fields
> -----------------
> Each driver record structure also needs a few additional fields if EXA
> support is to be used, e.g.:
Note that this isn't a recipe here. For example, most cards can
probably set up the offsets/pitch/bpp once during Setup and then ignore
them for future drawing calls.
> #if XF86EXA
> /* Container structure, describes card and accel. hooks */
> ExaDriverPtr EXADriverPtr;
>
> /* Optional fill parameters (see *Solid above) */
> int fillPitch, fillBpp, fillXoffs;
> CARD32 fillDstBase;
>
> /* Optional copy parameters (see *Copy above) */
> int copySXoffs, copyDXoffs, copyBpp;
> int copySPitch, copyDPitch;
> CARD32 copySrcBase, copyDstBase;
> int copyXdir, copyYdir;
>
> /* Offscreen scratch area pointer & accounting, you can implement this any
> * way you want. */
> ExaOffscreenArea *exa_scratch;
> unsigned int exa_scratch_next;
>
> /* Not sure if these are used?
> void (*ExaRenderCallback)(ScrnInfoPtr);
> Time ExaRenderTime;
Nope, these last couple wouldn't exist.
> EXA initialization
> ------------------
> Your driver's AccelInit routine has to initialize the EXADriverPtr and
> exa_scratch fields if EXA support is enabled, with appropriate error
> handling (i.e. NoAccel and NoXvideo should be set to true if EXA fails
> to initialize for whatever reason).
>
> A few, card specific fields need to be initialized:
>
> EXADriverPtr->card.memoryBase = ? /* base of the framebuffer */
> EXADriverPtr->card.memorySize = ? /* size of framebuffer */
> EXADriverPtr->card.offScreenBase = ? /* start of offscreen memory */
> /*
> * Common calculation is (maybe this should be the default?)
> * pScrn->virtualX * pScrn->virtualY * ((pScrn->bitsPerPixel * + 7) / 8)
> */
You've probably got alignment to do on your screen's pitch (virtualX),
so I'd guess not.
> /* Alignment restrictions for accessing card memory */
> EXADriverPtr->card.offscreenByteAlign = ?
> EXADriverPtr->card.offscreenPitch = ?
>
> /* Max screen size supported by the card? */
> EXADriverPtr->card.maxX = ?
> EXADriverPtr->card.maxY = ?
>
> The AccelInit routine also needs to make sure that there's enough
> offscreen memory for certain operations to function, like Xvideo, which
> needs at least as much offscreen memory as there is framebuffer memory?
I'd say that your Xvideo needs to adjust its maximum size advertised to
deal with however little offscreen memory you have available.
> [Is SiS broken here? It just checks to see if *any* offscreen memory is
> present, and assumes that's enough.]
>
> And of course all the callbacks you implemented as described above (with
> whatever names you've chosen):
>
> EXADriverPtr->accel.WaitMarker = WaitMarker;
>
> /* Solid fill & copy, the bare minimum */
> EXADriverPtr->accel.PrepareSolid = PrepareSolid;
> EXADriverPtr->accel.Solid = Solid;
> EXADriverPtr->accel.DoneSolid = DoneSolid;
> EXADriverPtr->accel.PrepareCopy = PrepareCopy;
> EXADriverPtr->accel.Copy = Copy;
> EXADriverPtr->accel.DoneCopy = DoneCopy;
>
> /* [How should composite be done?] */
>
> /* Upload, download to/from Screen, optional */
> EXADriverPtr->accel.UploadToScreen = UploadToScreen;
> EXADriverPtr->accel.DownloadFromScreen = DownloadFromScreen;
>
> After setting up the above, AccelInit should call exaDriverInit and pass in
> the current Screen and the new EXADriverPtr that was just allocated and filled
> out (don't forget to check for errors as that routine can fail). It should
> also allocate some offscreen memory for glyph data? using the
> exaOffscreenAlloc function, e.g.
>
> pDrv->exa_scratch = exaOffscreenAlloc(pScreen, 128 * 1024, 16, TRUE,
> ScratchSave, pDrv);
>
> /* Why is this required? Shouldn't exaOffscreenAlloc take care of it? */
> if(pDrv->exa_scratch) {
> pDrv->exa_scratch_next = pDrv->exa_scratch->offset;
> pDrv->EXADriverPtr->accel.UploadToScratch = UploadToScratch;
> }
Only use a scratch area if you don't have working UploadToScreen. Try
to get UploadToScreen working first -- scratch is a dirty hack.
> [How do we know how much to allocate for glyph data?]
You don't need much -- think of how big a line of text is, and that's
probably it. 256k is pretty generous, and will keep syncing to a
minimum.
> EXA teardown
> ------------
> At screen close time, EXA drivers should free any offscreen memory that
> was allocated, call exaDriverFini with their EXADriverPtr field, and
> free it, and do any other necessary teardown.
I would be surprised if they actually did have to free their memory, but
I haven't checked.
Thanks for attacking this documentation -- it's annoying stuff to write!
--
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org