1. Add 'GLXDrawable currentReadable' to the end of __GLXcontextRec.
2. Add 'bindContext2' to __DRIcontextRec. The DRI utility code would just hook bindContext2 directly to driBindContext2.
3. Add 'unbindContext2' to __DRIcontextRec. The DRI utility code would have to be updated. A new driUnbindContext2 would be added, and driUnbindContext would just call that. driUnbindContext2 would look exactly like driUnbindContext except that if the read and draw drawables passed in are different, it would decrement the ref. count on both.
All three of those changes should be pretty trivial. The hardest part will be writing glXMakeCurrentReadSGI / glXMakeContextCurrent. The existing glXMakeCurrent would serve as a model. I was thinking that all three functions (or at least the two new ones) could be just thin wrappers that call a single function that does the real work. Like my fbconfig code, the code would detect which flavor of the protocol to use. One nice thing about this is that we could support the SGI extension when the server supports GLX 1.3 but not the SGI extension (i.e., the current Nvidia drivers). I would welcome any comments (positive or negative) on that.
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.
What's a little bit less obvious to me is the changes that need to be made on the server side, but that can wait. :) I don't want to bite off more than I can chew...
------------------------------------------------------- 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
