Brian Paul wrote:
Ian Romanick wrote:
The question I have is about the interaction of driBindContext2 and driUnbindContext (both in lib/GL/dri/dri_util.c) with XF86DRIOpenFullScreen and XF86DRICloseFullScreen. It looks to me like this bit of protocol is only used when the env. var. LIBGL_DRI_AUTOFULLSCREEN is set.
From looking through both the client-side and the server-side code, it appears that this bit of protocol really only cares about the write drawable. If that is the case, then the protocol shouldn't need to be updated to support SGI_make_current_read or the parallel functionality in GLX 1.3. Is that correct?
If it really is only used when the env. var. is set, is there any chance we could just rip it out? Obviously it would have to be left as-is on the server-side, but it seems like the client-side support could go away.
I don't recall if the XF86DRIOpen/CloseFullScreen() functions are really used. I never worked on that path. I think it was meant for doing page-flipping swapbuffers, but I think Keith implemented that feature without using those functions.
Yes. As far as I'm concerned they can go away altogether.
That's the best news I've heard all day. :) In driBindContext2 I'm going to chop everything after the call to psp->DriverAPI.MakeCurrent. I will also chop the XF86DRICloseFullScreen call form driUnbindContext. Doing that leaves will_rebind unused. Since it's the last parameter to the function, is it safe to remove it? driUnbindContext2 will obviously not have this parameter...
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
