Adam Jackson wrote:
On Tuesday 19 April 2005 20:03, Dave Airlie wrote:
2) xf86dri.h and XF86dri.c that are part of mesa.
3) Some of the dri utils from mesa, basically to handle basic drawable
management and locking.
While doing this I notice that some (3) functions in XF86dri.c are
depending on Mesa headers and datatypes, and this does not seem to be
part of the original design, since it makes these files unusable
outside Mesa. These are
XF86DRICreateDrawable
XF86DRIDestroyDrawable
XF86DRICreateContext
I had a few others recently in my getting Radeon vha working, I used a few
XF86DRI functions, for now I've just linked libGL but I would like to see
them in a low level library..
My issue with exposing XF86DRI* as they are now is that they're direct
bindings to the XFree86-DRI protocol, which I don't think should be
app-visible at all. Consider the possibility of someone wanting to write a
DRI server that was not an X server. We should be enabling our competition.
Hrm. Conceptually these are really distinct from libdrm. They're requests to
a DRI server, not to a DRM kernel service. I'm not so sure how I feel about
this anymore.
You're right. All the XF86DRI functions are just implementing the
client side of the X11 DRI protocol.
However, any library or client using those will most likely use libdrm
as well, together with some utilities to manage locking and creation,
destruction and hashing of dri drawables.
My point was really to move the XF86DRI functions out of Mesa dri to a
separate library, and since libdrm.so could be used standalone and is
conceptually different there maybe should be one libdrm.so and one
libdriclient.so, or whatever we choose to call it.
/Thomas
- ajax
|
- Re: libminidri? Thomas Hellstrom
-
