Hi all,
As kindly hinted by Marek, currently we do have a wide selection of
supported dri <> loader combinations.
Although we like to think that things never break, we have to admit
that not many of us test every possible combinations of dri modules
and loaders. With the chances getting smaller as the time gap (age)
between the two increases. As such I would like to ask if we're
interested in gradually depreciating as the gap grows beyond X years.
The rough idea that I have in my mind is:
- Check for obsolete extensions (requirements for such) - both in the
dri modules and the loaders (including the xserver).
- Add some WARN messages ("You're using an old loader/DRI module.
Update to XXX or later") when such code path is hit.
- After X mesa releases, we remove the dri extension from the
module(s) and bump the requirement(s) in the loader(s).
And now the more important question why ?
- Very rarely tested and not actively supported - if it works it
works, we only cover one stable branch.
- Having a quick look at the the "if extension && extension.version
>= y" maze does leave most of us speechless.
- Will allow us to start removing a few of the nasty quirks/hacks
that we currently have laying around.
Worth mentioning:
- Depreciation period will be based on the longest time frame set by
LTS versions of distros. For example if Debian A ships X and mesa 3
years apart, while Ubuntu does is ~2.5 and RedHat ~2.8, we'll stick
with 3 years.
- libGL dri1 support... it's been almost four years since the removal
of the dri1 modules. Since then the only activity that I've noticed by
Connor Behan on the r128 front. Although it seems that he has covered
the ddx and is just looking at the kernel side of things. Should we
consider mesa X (10.6 ?) as the last one that supports such old
modules in it's libGL and give it a much needed cleanup ?
How would people feel about this - do we have any strong ack/nack
about the idea ? Are there many people/companies that support distros
where the xserver <> mesa gap is over, say 2 years ?
Looking forward to any feedback,
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
