[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#464353: How can we provide more info ?



On Wed, Mar 19, 2008 at 21:37:56 +0100, Apelete Seketeli wrote:

> On Wed, Mar 19, 2008 at 6:33 PM, Michel Dänzer <daenzer@debian.org> wrote:
> 
> >
> > > (and using "ExaNoComposite" "false"does improve compositing if you use
> > > "MigrationHeuristic" "greedy", but that's out of subject).
> >
> > >>That's the default, so it shouldn't make any difference...
> 
> 
> It's indeed written in EXA man pages that it's the default, and as you've
> written it  shouldn't make any difference....it  shouldn't but it DOES.
> Actually, without the ExaNoComposite option,  the driver registered the
> composite operation (render acceleration), but once you use that option, you
> can read in the xorg log file: "EXA: Disabling Composite operation (RENDER
> acceleration)". Moreover it doesn't matter whether you use "false" or
> "true", they both disable the composite operation...looks like a bug to
> me...
> Sorry for the digression :-)
> 
from hw/xfree86/exa/examodule.c:
    if (xf86IsOptionSet(pScreenPriv->options, EXAOPT_NO_COMPOSITE)) {
        xf86DrvMsg(pScreen->myNum, X_INFO,
                   "EXA: Disabling Composite operation "
                   "(RENDER acceleration)\n");
        pExaScr->info->CheckComposite = NULL;
        pExaScr->info->PrepareComposite = NULL;
    }

That's broken.  xf86IsOptionSet()'s return value is TRUE if the option
is specified in xorg.conf, whether it's set to true or false.  I believe
this should use xf86ReturnOptValBool() or xf86GetOptValBool().
All exa options seem to share this bug.

Cheers,
Julien



Reply to: