RandR (etc) DriverFunc

[Egbert Eich]

Thomas Winischhofer writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > 
 > xf86str.h states that the driver should return FALSE if a driver
 > function is not supported.
 > 
 > This does not comply with the current use of DriverFunc, namely in
 > xf86RandR.c. If the driver returns FALSE there, the function calling the
 > driver function will fail.
 > 
 > So, either we should change the default behavior to return TRUE in the
 > driver func if the function opcode is not understood by the driver, or
 > change the existing code not to bail out on FALSE.
 > 

You definitely have a point there.
In the case of xf86RandRGetInfo() we definitely should return TRUE.
In the case of xf86RandRSetConfig() I'm not clear about the semantics
of the driver func. 
Should this function do rotation and mode switching (we are passing
size information)?
I would think currently:

 if (randrp->rotation != rotation) {

    /* Have the driver do its thing. */
        if (scrp->DriverFunc) {
            xorgRRRotation RRRotation;
            RRRotation.RRConfig.rotation = rotation;
            RRRotation.RRConfig.rate = rate;
            RRRotation.RRConfig.width = pSize->width;
            RRRotation.RRConfig.height = pSize->height;

            /*
             * Currently we need to rely on HW support for rotation.
             */
            if (!(*scrp->DriverFunc)(scrp, RR_SET_CONFIG, &RRRotation))
                return FALSE;
        }
        randrp->rotation = rotation;
    }

would do as we don't support SW rotation any change in rotation would
have to be handled by the driver.
In any other case we'd need to have a SW fallback - however then we 
may consider calling the DriverFunc() from inside xf86RandRSetMode ().

I'm going to submit a patch.

Egbert.