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.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
