On Wed, Jan 12, 2005 at 08:38:54AM -0700, Marc Aurele La France wrote: >On Tue, 11 Jan 2005, Kevin E Martin wrote: >>On Tue, Jan 11, 2005 at 02:15:58PM -0700, Marc Aurele La France wrote: >>>On Tue, 11 Jan 2005, Marc Aurele La France wrote: >>>>On Tue, 11 Jan 2005, Kevin E Martin wrote: >>>>>Here's an explanation of the issue with a proposed fix to maintain >>>>>backward compatibility: > >>>>> http://sourceforge.net/mailarchive/message.php?msg_id=10290987 > >>>>>I've tested my patch to make sure that it works fine on Linux. I don't >>>>>have an SGI box to verify that it still works fine on their systems. > >>>>Well, if I were you, I'd commit something like that ASAP. I can deal >>>>with >>>>the build issues, test case or no test case. The point being that no one >>>>will fix it if it doesn't build. > >>>>Longer term though, we need to look at glxProxy being more of an >>>>#ifdef'ed >>>>derivative of GLX. > >>>Come to think of it, I'll be even blunter. If DMX breaks every time GLX >>>is >>>resync'ed, then there's no point in keeping DMX. > >>glxProxy was developed by SGI is almost 100% independent from GLX as >>used in the rest of the X server -- the only shared code is from some >>header files. One of those headers was changed but not properly >>#ifdef'd by SGI to maintain backward compatibility with previous XFree86 >>releases. The patch that I suggested fixes the backward compatibility >>issue. This is all explained in the thread that I referenced in my >>previous message. > >>Unfortunately, I just discovered that there is a much more significant >>issue: you've made changes to glxProxy on 4 Aug 2004 that broke the >>build. I've attached a patch to make it build again. However, I cannot >>verify the correctness of the changes you've made, since glxProxy is not >>my code. As I mentioned above, the code was donated by SGI. I would >>strongly suggest reverting the changes you've made until you can verify >>with SGI that your changes are correct. > >>If you do revert the changes back to the way they were originally >>checked in and then apply the patch from my message to the dri-devel >>list (see URL above), then glxProxy should build and work properly, and >>it should also be backward compatible with previous XFree86 releases. > >SGI's own compiler could not build what was originally committed for >glxProxy, and GCC was also quite noisy about it. Were this not so, I >probably would not even have noticed that there a much much larger issue >here. > >As I reported back in August, the GLX protocol understood by glxProxy is >significantly different from, and in many respects incompatible with, any >native GLX implementation we've ever provided. In effect, we are being >asked to harbour and maintain a transport for a GLX implementation whose >end-points are not within our purview to support. If you care to examine >glxProxy more closely, you will see that it is based on a separate, likely >SGI-internal, GLX snapshot. I wouldn't mind so much if Xdmx were more >lbxproxy-like, but that's not the case here. Fortunately, GLX is the only >extension Xdmx provides its own framework for. It would also seem your >glxProxy testing only relied on a common subset of GLX. > >I also stated back then that my changes, in addition to fixing build >issues, also represented a first, necessarily incomplete, swipe at >re-aligning glxProxy's GLX implementation with what we actually provide >natively, and that my familiarity with GLX was insufficient to complete the >job. I even asked for help and/or comments. > >All this, apparently, fell on deaf ears. > >My August changes were based on the GLX that was then in our repository, >and that glxProxy's build is broken since Alan's latest merge only furthers >my point. > >I have no objection to re-instating DMX builds. Yet, on these grounds, I >remain adamanant that SGI's glxProxy, as it currently stands, is >unacceptable for inclusion into 4.5, with or without (un-)changes to make >it build.
That sounds like the way to go. Re-instate the DMX builds, minus glxProxy. When/if the glxProxy issues, including re-alignment with the GLX implementation we provide natively, are resolved it can be reinstated. If this doesn't happen, it should be pulled. David _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
