From: Alan H. <al...@fa...> - 2004-12-10 19:05:09
|
Folks, There's a backwards compatibility breakage with X.Org 6.8.0 and beyond because of revision 1.3 of the file xc/include/glxint.h. So, those that provide binary drivers that were compiled against X.Org 6.7.x or XFree86 4.4.0 or earlier will break as well. The problem stems from these additional fields in the GLXvisualConfigRec which actually are not needed. int multiSampleSize; int nMultiSampleBuffers; int visualSelectGroup; These fields are already in the new GLXFBConfigRec for the later FB visual selection code. What exactly happens is that only the first visual is actually exported with a matching GLX visual attribute. The DDX driver uses GLXvisualConfigRec to allocate a list of visuals and passes them off to GLX to register them. Because the size of the structure changed, older GLX's barf on registering the visuals apart from the first. Now, I guess I'm a little unsure of what to do about this now that 6.8.0 broke it. But it's definately a problem for those IHV's or binary folks that provide their own drivers without having to upgrade a plethora of other modules too. Ideas ? Maybe for the future, we should have a function that the driver can call to allocate this block of GLX visuals, that's handled in libglx.a. That way only a pointer is handed back to the DDX driver to fill in what it actually knows about. But versioning bumping required here and I'm not sure it's worth it given the new FB selection code anyway. Alan. |
From: Alan H. <al...@fa...> - 2004-12-11 00:52:57
|
On Fri, Dec 10, 2004 at 07:04:51PM +0000, Alan Hourihane wrote: > Folks, > > There's a backwards compatibility breakage with X.Org 6.8.0 and beyond > because of revision 1.3 of the file xc/include/glxint.h. So, those > that provide binary drivers that were compiled against X.Org 6.7.x or > XFree86 4.4.0 or earlier will break as well. > > The problem stems from these additional fields in the GLXvisualConfigRec > which actually are not needed. > > int multiSampleSize; > int nMultiSampleBuffers; > int visualSelectGroup; Ah, It seems as though the DMX code probably added these as it makes use of them. Alan. |
From: Kevin E M. <ke...@fr...> - 2004-12-13 02:55:58
Attachments:
glxproxy-compat.patch
|
On Sat, Dec 11, 2004 at 12:52:45AM +0000, Alan Hourihane wrote: > On Fri, Dec 10, 2004 at 07:04:51PM +0000, Alan Hourihane wrote: > > Folks, > > > > There's a backwards compatibility breakage with X.Org 6.8.0 and beyond > > because of revision 1.3 of the file xc/include/glxint.h. So, those > > that provide binary drivers that were compiled against X.Org 6.7.x or > > XFree86 4.4.0 or earlier will break as well. > > > > The problem stems from these additional fields in the GLXvisualConfigRec > > which actually are not needed. > > > > int multiSampleSize; > > int nMultiSampleBuffers; > > int visualSelectGroup; > > Ah, > > It seems as though the DMX code probably added these as it makes use > of them. I just checked and these were added by SGI when they did their glxProxy work that was included with DMX. Guy Zadikario <gu...@sg...> was the principle author of glxProxy. I would recommend contacting him to see if there is another way to implement support for the additional extended visual properties that would maintain backwards compatibility. I assume they were added to support SGI's OpenGL implementation. One workaround is to surround those fields in GLXvisualConfigRec and the glxProxy code that uses those fields with #ifdef __sgi/#endif (see patch attached below). This would be good to do for 6.8.2 to regain backwards compatibility. Alan, do you have a test case that you could use to make sure that I've not missed anything? Also, I've created a bugzilla entry for this problem: https://bugs.freedesktop.org/show_bug.cgi?id=2070 Thanks, Kevin |
From: Alan C. <al...@lx...> - 2004-12-13 15:44:02
|
Does this not break compatibility with 6.8.0/6.8.1 - that seems at least as big a problem as the breakage from 6.7 because it will prevent anyone stuck with a 6.8.* driver from updating to get security fixes ? |
From: Kevin E M. <ke...@fr...> - 2004-12-13 19:29:07
|
On Mon, Dec 13, 2004 at 11:30:07AM +0000, Alan Cox wrote: > Does this not break compatibility with 6.8.0/6.8.1 - that seems at least > as big a problem as the breakage from 6.7 because it will prevent anyone > stuck with a 6.8.* driver from updating to get security fixes ? We discussed this issue on the release wranglers call today 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 vendors that rely on the DRI. We plan to investigate other solutions for the next major release. Kevin |
From: Ian R. <id...@us...> - 2004-12-13 19:29:18
|
Alan Hourihane wrote: > There's a backwards compatibility breakage with X.Org 6.8.0 and beyond > because of revision 1.3 of the file xc/include/glxint.h. So, those > that provide binary drivers that were compiled against X.Org 6.7.x or > XFree86 4.4.0 or earlier will break as well. So, the real answer to this problem is that the interface between libglx.a, libGLcore.a, and the DDX is horribly broken. With respect to 3D, there is no clean division between the three. Each directly allocates, rearranges, and modifies various datastructures. For the current Xorg release (6.8.x), I'm content to leave things as they were in 6.8.0. For the next major release (6.9.0) I believe that the entire existing interface on the server-side needs to be pitched in the garbage. Ideally, we want the libglx / libGLcore interface to be identical to the libGL / *_dri.so interface. On the client-side libGL *does* provide and function to allocate and initialize (with default values) __GLcontextModesRec structures. > > The problem stems from these additional fields in the GLXvisualConfigRec > which actually are not needed. > > int multiSampleSize; > int nMultiSampleBuffers; > int visualSelectGroup; > > These fields are already in the new GLXFBConfigRec for the later FB visual > selection code. Hmm...this is bad. Anything that makes any chages to GLXvisualConfigRec will break the hell out of a lot of things. That's why the "real" selection code in libglx abandoned that structure in favor of __GLcontextModesRec. |