On Fri, 2005-01-14 at 16:47 +0100, Roland Scheidegger wrote:
>
> 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.
I consider these options more or less unacceptable.
> 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).
The more I think about this, the more I like it. I think we could take
this a bit further even to make it more or less equivalent with option
3):
* The DDX sets its major version according to the features its
configuration requires clients to support.
* Clients accept all major DDX versions they can support.
* The minor DDX version increases monotonically, regardless of the
major version.
This would effectively change the meaning of the major and minor
versions (the minor version would more or less remain the denominator of
what the DDX supports, whereas the major version would now express what
it expects from the client), so it requires a lot of thought and broad
consensus. So far I think it would be a change for the better, what does
everybody else think?
> 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.
That's easy: no version means the client doesn't support anything
covered by the versioning.
> Also, I'm not sure how easy exactly it would be to let dri client
> initialization fail based on current ddx config.
That's my biggest concern as well. Ian, do you think something like this
would be possible without breaking the current interface between libGL
and the drivers?
> 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)?
All the DRI interfaces were only versioned in one direction initially;
that was probably assumed to be sufficient at the time they were
designed. Only recently has it been discovered that two-way versioning
can be useful for situations where the major version would have to be
bumped otherwise.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
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
