Bug 2070

Summary: glxProxy breaks backwards compatibility
Product: xorg Reporter: Kevin E. Martin <kem>
Component: Server/DDX/dmxAssignee: Adam Jackson <ajax>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: high CC: dberkholz, erik.andren
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 5041    
Attachments:
Description Flags
Workaround to restore backwards compatibility roland.mainz: 6.8-branch-

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 Adam Jackson 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 Adam Jackson 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.

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.