Currently, dri drivers don't have a version number, and the server-side dri code thus cannot refuse to load a driver if the respective ddx code needs a new dri driver. So, would it be helpful to implement version numbers in dri and introduce a a new dri function (Michel Dänzer suggested XF86DRISetClientVersion()) which allows a dri client to announce its version?
You should be careful about terminology. If the version that the client advertises is the client's expected DDX version, then this seems feasible. If you want to introduce a new "client version", then that goes against the idea of the X server providing services which anyone can write a client to use.
My experience with extending the basic backwards compatiblity requirements of the DRI driver components is that the code for backwards compatibility quickly becomes untested and krufty, and even though it probably ceased working months or years ago, people are unwilling to remove it. It's hard enough keeping the current combination of driver compents working together without worrying about emulating the behaviour of older ones.
Your option 2b seems reasonable.
Keith
------------------------------------------------------- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
