Bug 2070 - glxProxy breaks backwards compatibility
glxProxy breaks backwards compatibility
Status: RESOLVED WONTFIX
Product: xorg
Classification: Unclassified
Component: Server/DDX/dmx
git
x86 (IA32) Linux (All)
: high normal
Assigned To: ajax at nwnk dot net
:
Depends on:
Blocks: 5041
  Show dependency treegraph
 
Reported: 2004-12-12 18:42 UTC by Kevin E. Martin
Modified: 2006-04-30 13:45 UTC (History)
2 users (show)

See Also:


Attachments
Workaround to restore backwards compatibility (4.07 KB, patch)
2004-12-12 18:48 UTC, Kevin E. Martin
roland.mainz: 6.8‑branch-
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin E. Martin 2004-12-12 18:42:38 UTC
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
Comment 1 Kevin E. Martin 2004-12-12 18:48:41 UTC
Created attachment 1532 [details] [review]
Workaround to restore backwards compatibility
Comment 2 Kevin E. Martin 2004-12-12 18:57:10 UTC
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 3 Roland Mainz 2004-12-14 11:53:47 UTC
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.
Comment 4 Kevin E. Martin 2004-12-15 07:42:03 UTC
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.
Comment 5 Erik Andren 2006-04-27 07:05:09 UTC
Is this still an issue with a current version of xorg?
Comment 6 Kevin E. Martin 2006-04-27 07:22:22 UTC
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.
Comment 7 ajax at nwnk dot net 2006-04-29 01:05:35 UTC
(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?
Comment 8 Kevin E. Martin 2006-04-29 01:30:11 UTC
(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.
Comment 9 ajax at nwnk dot net 2006-05-01 06:45:08 UTC
(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.