On 10/12/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
...
> > The DRI driver interface changes I'm proposing here should not be
> > affected by these issues though. Detecting that the buffers changed
> > and allocating and attaching new ones is entirely between the DRI
> > driver and the DRM. When we're ready to add the TTM functionality to
> > a driver we add the new createNewScreen entry point I mentioned and
> > that's all we need to change. So, in other words, I believe we can
> > move forward with this merge while we figure out the semantics of the
> > resizing-while-rendering case.
>
> Meanwhile though, these changes already drop support for existing
> loaders, right? That's rather inconvenient for AIGLX, not so much for
> libGL. I don't suppose it would be reasonably possible to retain support
> for __driCreateNewScreen_20050727, at least until there's an xserver
> release that supports the new one? If not, I wonder if it might be worth
> holding off a bit longer until the changes will provide real benefits
> such as new GLX features, as otherwise they would seem to require
> inter-component lockstep for little gain.
They do drop support, yes, but of course, I'm committing a series of X
server patches along with this to let AIGLX load the new driver API.
This means that you can't load a git dri driver with any released X
server, which is the inconvenience you're referring to I guess. I do
think it's worth moving forward with this though. Personally, I get
these patches off of my plate and can focus on the next steps. We get
the patches upstream which will get them tested, and I think this is
important, since there's a lot more work in the pipeline from
everybody, so any early testing we can do is very much worth it.
Finally, along with the X server patches, this does land new features.
With these patches I can land the X server work to enable GLX 1.4
support and the visual cleanup, we just wont be able to advertise any
GLXPixmap or GLXPbuffer capable fbconfigs yet.
> Apart from that, the changes look good to me, with one exception:
> b068af2f3b890bec26a186e9d0bdd3d44c17cd4d ('Key drm_i915_flip_t typedef
> off of the ioctl #define instead.'). DRM_IOCTL_I915_FLIP was already
> defined before drm_i915_flip_t and friends were introduced.
Yup, my bad, I didn't install the libdrm pkg-config file.
cheers,
Kristian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel