[Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Ian Romanick]

On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
> On May 16, 2017 18:30:00 Timothy Arceri <tarceri at itsqueeze.com> wrote:
> 
>> On 17/05/17 02:38, Ian Romanick wrote:
>>> What *actual* problem are you trying to solve?  Honestly, it seems like
>>> you're just trying to find stuff to do.  We have a mechanism to make
>>> this work, and it's not that hard.  Introducing a deprecation period and
>>> everything that involves will make it more work, not less.
> 
> I think that's a fair question
> 
>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
>> on tidying-up / optimisations. It's not like there are large spec
>> updates in the pipeline.
> 
> If we are genuinely making things more maintainable, then maybe
> deprecation is reasonable.  However, of it's just churn, then it may
> just be a source of new bugs to fix.  I think asking "why?" is perfectly
> reasonable.
> 
> On the other side, perhaps we should consider instead taking advantage
> of the backwards comparability and dropping some of the old and
> unmaintained drivers from the tree, put them on a critical-bugfix-only
> branch, and recommend that distros build two mesas and only install the
> loader from the newer one.  Dropping i915, r200, and other effectively
> unmaintained drivers from the tree would make it much easier to do core
> state tracker cleanups since there would effectively only be two state
> trackers: gallium and i915. For example, there's a lot of code floating
> around for dealing with hardware that doesn't have native integers.

r300 and r400 in Gallium do not have native integers.  I don't know
about NV30.

I wanted to remove support for NV04 and NV05 last year because they are
unused, unmaintained, and demonstrably *broken*, and I could not even
get consensus on that.

> --Jason