Alan Hourihane found that the additional extended visual properties that were added by SGI for glxProxy breaks backwards compatibility with previous releases. See the following for a more complete description of the problem: http://lists.freedesktop.org/pipermail/release-wranglers/2004-December/001512.html
Created attachment 1532 [details] [review] Workaround to restore backwards compatibility
Comment on attachment 1532 [details] [review] Workaround to restore backwards compatibility Restore backwards compatibility by limiting the additional extended visual properties to SGI only. Patch not checked into HEAD since this is a workaround and better solutions should be investigated for the next major release.
Comment on attachment 1532 [details] [review] Workaround to restore backwards compatibility Approval for X11R6.8.x stable branch DENIED in the 2004-12-13 release-wranglers phone call as this breaks the ABI within the X11R6.8.x release series.
We discussed this issue on the release wranglers call 13 Dec 2004 and decided to maintain compatibility with 6.8 for this and future 6.8-based point releases instead of restoring backwards compatibility with 6.7 since an ABI change now would cause additional problems for vendors that rely on the DRI. Other solutions should be investigated for the next major release.
Is this still an issue with a current version of xorg?
Yes, backward compatibility with 6.7 is still an issue, but since we have already had the 6.9/7.0 release I don't think we should consider it as something that should be changed at this point unless there is a very strong reason to do so. I'll mark it as a blocker of the current (7.1) release so that it can be considered.
(In reply to comment #6) > Yes, backward compatibility with 6.7 is still an issue, but since we have > already had the 6.9/7.0 release I don't think we should consider it as something > that should be changed at this point unless there is a very strong reason to do so. > > I'll mark it as a blocker of the current (7.1) release so that it can be considered. i'm inclined to skip this for 7.1. we managed to not break the DRI ABI this time around, and we're definitely going to break it when we redo static front buffer allocation, so I'd prefer to defer this to then. kevin, does this sound reasonable?
(In reply to comment #7) > i'm inclined to skip this for 7.1. we managed to not break the DRI ABI this > time around, and we're definitely going to break it when we redo static front > buffer allocation, so I'd prefer to defer this to then. > > kevin, does this sound reasonable? Yes it does. For the future, there are two somewhat separate issue here... (1) What do we want to maintain backward compatibility with -- either XF86 4.4/Xorg 6.7 or Xorg 6.[89]/7.[01]? I'm tempted to simply say we'll maintain compability with 6.[89]/7.[01] and leave things the way they are, which means we could close the bug as WONTFIX; and (2) Is there a compelling technical reason to make this change? I haven't come up with any to date, but if someone can come up with one, I'm happy to listen.
(In reply to comment #8) > (1) What do we want to maintain backward compatibility with -- either XF86 > 4.4/Xorg 6.7 or Xorg 6.[89]/7.[01]? I'm tempted to simply say we'll maintain > compability with 6.[89]/7.[01] and leave things the way they are, which means we > could close the bug as WONTFIX; and Agreed. > (2) Is there a compelling technical reason to make this change? I haven't come > up with any to date, but if someone can come up with one, I'm happy to listen. I can't think of one either. If the extra visual properties really need to be handled at some point, we should probably only do so for Xdmx and not for the core glx code.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.