[PATCH] DRI2: fixup handling of last_swap_target

Jesse Barnes jbarnes at virtuousgeek.org
Sun Mar 7 09:13:58 PST 2010


On Sun, 07 Mar 2010 15:38:24 +0100
Michel Dänzer <michel at daenzer.net> wrote:

> On Sun, 2010-03-07 at 08:44 +0100, Mario Kleiner wrote: 
> > 
> > Your deferred pPriv deletion logic looks now good to me. But if  
> > deletion is deferred then i think almost all "public" functions  
> > inside dri2.c should return 'BadDrawable' not only for pPriv == NULL  
> > but also for pPriv->refCount == 0, e.g., DRI2SwapBuffers,  
> > DRI2GetMSC, ... From the viewpoint of client code, a refCount == 0 is  
> > the same as a destroyed drawable. For all practical purposes it is  
> > already gone. Maybe it would make sense to consolidate the (pPriv ==  
> > NULL || pPriv->refCount == 0) check into a macro or function,  
> > something like DRI2IsDrawableAlive(pPriv); and then call that in most  
> > DRI2xxx functions?
> 
> Sounds like a good idea to me FWIW.
> 
> Speaking of consolidation: Is it just me, or do the X server <-> driver
> interfaces you guys have been discussing seem to require way too much
> brains in the drivers which should rather be centralized in the server?
> (I admit I've only been skimming the code and discussion, so my
> impression may be wrong)

We've gone back and forth on that a bit.  My initial version had more
logic (all the event handling in particular) in the server.  The main
problem with that was it created an unintuitive split for doing things
like page flipping.  But more than that, the vblank count and DRM
handling really belongs in the DDX, and splitting that up also caused
some weirdness in terms of the interfaces.

The interfaces we have now do require the DDX to do a bit of work, but
they also allow it to do nice things like page flipping and virtualize
the vblank count if they want.

That said, I'd have no problem factoring out common functionality as
other drivers grow support for these features.  At the very least we
could probably provide a DRI2 driver module that did some DRM
interactions (so as to keep those bits of code out of the core DRI2
module).

-- 
Jesse Barnes, Intel Open Source Technology Center


More information about the xorg-devel mailing list