[Mesa-dev] [RFC] Compatibility between old dri modules and new loaders, and vice verse

Dave Airlie airlied at gmail.com
Mon Jun 22 15:19:45 PDT 2015

On 23 June 2015 at 08:16, Ian Romanick <idr at freedesktop.org> wrote:
> On 06/22/2015 11:54 AM, Dave Airlie wrote:
>>> 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 ?
>> We still ship 7.11 based dri1 drivers in RHEL6, and there is still a
>> chance of us rebasing to newer Mesa in that depending on schedules.
>> ajax might have a different opinion, on how likely that is, but
>> that would be at least another year from now where we'd want DRI1
>> to work.
> A time line would be good.  I think it will take a fair amount of time
> to get a new loader<>driver interface in order.  If we can't change
> anything for two years, then there's not a lot of point to thinking
> about it now.  If it's a year or less away, that's a different story.
> The other possibility would be for RHEL to ship more than one libGL...
> one for DRI1 drivers and one for everything else.  I don't know how
> horrible that would be.

That would worse than impossible, it's bad enough nvidia overwrite
libGL I don't want us to do it as well to ourselves :-)


More information about the mesa-dev mailing list