On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote: > On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: > > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: > > > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: > > > > > - add code to Mesa so GetMSC/WaitForMSC set > > > > > DRM_VBLANK_SECONDARY correctly > > > > > > > > One idea (with some handwaving :) would be the common code > > > > keeping around a pointer to the driver's vblank_flags variable or > > > > keeping track of the flags per drawable in some other sensible > > > > way. > > > > > > I like the idea, here's something concrete. I put the vblank stuff > > > into the screen private, but I'm not sure if that's the best place > > > (logically the vblank counters are screen specific), > > > > The drawable private would seem more appropriate, as these are > > drawable attributes. > > Here's a new version
Where's that? :) > that moves the new fields over to the drawable private. I added a new > drawable hook to implement the callback, and in the process discovered > that all the drivers I could find either set their MSC routines to > NULL or used the generic calls. > > So I didn't bother creating a new driver API hook for the new call; I > just set it directly to the version in vblank.c in > driCreateNewDrawable(). > > Would it make sense to rip out all the wrappers in dri_util.c, set > everything directly in driCreateNewDrawable() and > driUtilCreateNewScreen()? What exactly do you mean by 'all the wrappers'? > It seems that drivers that set their MSC routines to NULL will return > GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g. > drmWaitVBlank() failed clients would get the same result, so > compatibility would be preserved... Isn't the presence or absence of the driver hooks used to decide whether or not to advertise the GLX extension(s) though? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
