Bug 2070

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.