Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<> wrote:
 The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to 
 fill the private sarea from the back, but that would break DDX tests for
size of usable area.
 Different sareas are allocated using drmAddMap with type=DRM_SHM. The one
containing the current hardware lock is specified with the flag

Shouldn't the sarea have been allocated by the driver in the first
place? Maybe this is another place for pemanent maps. I will probably
have to change this for multihead support running indenpendent X
servers. The current design assumes a master process that
creates/deletes sarea and that isn't the case for indepenent

Code like this is a mistake:
drmInfo.sarea_priv_offset   = sizeof(drm_sarea_t);

The first member of drm_sarea_t should have been an offset to the
private sarea. Doing it that way would automatically adjust if the
size of drm_sarea_t is changed. Offset should have been filled in by
the DRM driver.

I don't see any code computing sizeof(drm_sarea_t) +
sizeof(drm_xxx_sarea_t). What is getting stored in the SAREA page
after the private area?

X contains code like

    /* For now the mapping works by using a fixed size defined
    * in the SAREA header
    if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
    xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
            "Data does not fit in SAREA\n");
    return FALSE;
    pDRIInfo->SAREASize = SAREA_MAX;

So if locks are going to be squeezed in somewhere I'd either have to fit them in the
XF86DRISAREARec or put them into every driver's private area.

BTW, The "Old" drm functionality and design was very well documented by precision insight / VAlinux.  Now that  permanent maps are introduced and new requirements are made on the hw-specific drivers, is there a chance that these documents could be updated?