From: Ian R. <id...@us...> - 2003-12-30 03:49:26
|
Ian Romanick wrote: > Log message: > All of the libglx.a and libGLcore.a code now uses __GLcontextModes to > track FBconfigs / visuals. Just a heads up. The next step will be to enable "fake" support for SGIX_fbconfig on the server-side. Basically, I will just assign an FBconfig ID to the visuals supplied by the DDX driver. Once that is done and the server-side protocol support is added, we'll be able to advertise SGIX_fbconfig! Yay. Once that is done, I would like to have help modifying *all* of the drivers to use the new interfaces. After that, I think it will be safe to merge it all to the trunk. There is a subtle issue there, which was discussed some at the dri-devel chat today. Where should the per-driver changes be committed? We came up with three options, and, quite frankly, I'm not too fond of any of them. 1. Commit the changed files to the DRI tree and patch up the Imakefiles to use the files in the DRI tree instead of the unchanged files in the Mesa tree. 2. Create a driinterface-0-0-2 branch in the Mesa tree and commit the changes there. 3. Commit the changes to the trunk of the Mesa tree. The modified drivers need to work with old libGL.so binaries, and this would be a way to be sure of that. :) Option #1 is, after further consideration, really bad. Options #2 and #3 are close, but I'm leaning towards #3. Opinions? |
From: Keith W. <ke...@tu...> - 2004-01-04 23:09:41
|
Ian Romanick wrote: > Ian Romanick wrote: > >> Log message: >> All of the libglx.a and libGLcore.a code now uses __GLcontextModes to >> track FBconfigs / visuals. > > > Just a heads up. The next step will be to enable "fake" support for > SGIX_fbconfig on the server-side. Basically, I will just assign an > FBconfig ID to the visuals supplied by the DDX driver. Once that is > done and the server-side protocol support is added, we'll be able to > advertise SGIX_fbconfig! Yay. > > Once that is done, I would like to have help modifying *all* of the > drivers to use the new interfaces. After that, I think it will be safe > to merge it all to the trunk. There is a subtle issue there, which was > discussed some at the dri-devel chat today. Where should the per-driver > changes be committed? We came up with three options, and, quite > frankly, I'm not too fond of any of them. > > 1. Commit the changed files to the DRI tree and patch up the Imakefiles > to use the files in the DRI tree instead of the unchanged files in the > Mesa tree. > > 2. Create a driinterface-0-0-2 branch in the Mesa tree and commit the > changes there. > > 3. Commit the changes to the trunk of the Mesa tree. The modified > drivers need to work with old libGL.so binaries, and this would be a way > to be sure of that. :) > > Option #1 is, after further consideration, really bad. Options #2 and > #3 are close, but I'm leaning towards #3. Opinions? Unlike the DRI, mesa is organized with the trunk as the 'development' branch and stable branches being periodically created off it. Truely speculative development in mesa belongs on a branch (eg anything that will be expected to break all or most of mesa), but regular type development should go on the trunk. I actually think this is a much better system as people (should) know where to go to get a stable Mesa, but the development Mesa's get a lot more testing than is the case with things stuck on branches in the DRI tree. Keith |