On Wed, Nov 29, 2017 at 4:19 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 25.11.2017 18:46, Jason Ekstrand wrote: > >> I'm not quite some sure what I think about this. I think I would like to >> see $new_thing at least replace the guts of GBM. Whether GBM becomes a >> wrapper around $new_thing or $new_thing implements the GBM API, I'm not >> sure. What I don't think I want is to see GBM development continuing on >> it's own so we have two competing solutions. >> >> I *think* I like the idea of having $new_thing implement GBM as a >> deprecated legacy API. Whether that means we start by pulling GBM out into >> it's own project or we start over, I don't know. My feeling is that the >> current dri_interface is *not* what we want which is why starting with GBM >> makes me nervous. >> > > Why not? > > The most basic part of the dri_interface is just a > __driDriverGetExtensions_xxx function that returns an array of pointers to > extension structures derived from __DRIextension. > > That is *perfectly fine*. > Fair enough. I'm perfectly happy to re-use a well-tested API extension mechanism. > I completely agree if you limit your statement to saying that the current > *set of extensions* that are exposed by this interface are full of X-isms, > and it's a good idea to do a thorough house-cleaning in there. This can go > all the way up to eventually phasing out the DRI_Core "extension" as far as > I'm concerned. > That's more of what I was getting at. In particular, I don't want the design of $new_thing to be constrained by trying to cram into the current DRI extensions nor do I want it to attempt to have exactly the same set of functionality as the current DRI extensions (or GBM) support.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
