This is in reference to the radeon tiling, but it might of course be useful for other things. Currently, if ddx changes and makes it at least "partially incompatible" (that is, it might still be compatible depending on the options used), there is no other way than to increase the ddx major version to make a dri client connection fail (and this is done client-side, not server-side).
Basically, there are 3 options to handle it:
1) ignore the problem. This might be ok if the ddx is only incompatible when a certain option is enabled, as long as it stays off by default maybe (i.e. user has enabled the option, so assume he knows what he's doing and he can make sure dri client driver is new enough himself).
2a) increase ddx major number. Gets rid of the compatiblity issues by forcing to only accept a new dri driver - even if it might not be needed (depending on the ddx driver options used). Also, new dri drivers will fail to load with old ddx unnecessarily.
2b) same as above, but tweak the client-side ddx version check to allow for ranges of ddx major versions instead of a single ddx major version (so new dri drivers can work with both old and new ddx, but new ddx will still require new dri driver).
3) extend the dri api as outlined above (and bump the XF86DRI_MINOR_VERSION), and then let XF86DRIGetDeviceInfo() fail if the dri client version is too old to be compatible with the current ddx configuration. So you'd only need a new dri driver when it's actually required.
So, option 3) sounds elegant, though I'm still not sure it's actually worth the trouble:
a) complexity / compatiblity. Things like old libGL, new Xserver, or vice versa come to mind. Also, dri drivers now need version numbers, and server side code needs to deal with drivers which don't have them yet. Also, I'm not sure how easy exactly it would be to let dri client initialization fail based on current ddx config.
And, I'm not sure I could implement that correctly, if possible at all wrt to compatibility, but it definitely seems to involve quite some hassle.
Are there specific reasons why dri drivers don't have version numbers in the first place (maybe it was considered to add only unnecessary complexity)?
b) it seems to achieve relatively little (imho) over solution 2b). If the new ddx option which makes it incompatible is enabled by default (which I'd intend to do for tiling), the practical consequences are pretty much identical. Unless someone really insists on using new ddx and old dri (and thus would switch the option off).
Comments?
Roland
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
