Adam Jackson wrote:
In this discussion it's important to not forget non-OpenGL dri clients.
Both lib810XvMC and libviaXvMC use libdrm code, but they actually
symlink only needed source files from the libdrm source and compile
them directly into the library. I see no reason, however, why they
shouldn't be able to use a dynamic so instead.
On Thursday 30 December 2004 21:44, Jon Smirl wrote:
I've been out of the DRI loop for a while since all I do is help feed
and change two crying babies, but we also need think about the GL
standalone case. libdrm is linked into the dri.so's so that they can
be used standalone. Wouldn't another solution be to just fix the
DRI.so's to not export the libdrm symbols?
Maybe. Depends on if the linker would choose to resolve the drm symbols from
the server's libdrm module or from the ones linked statically into the
driver. But then you still have two copies of the same code in the same
process and attempting to use the same symbols, and to me that sounds like a
If we proceed down the X on
GL path this problem would go away since X would stop using libdrm.
No, it won't. For X on GL, the server still loads a DRI driver. It's just
already loaded early during eglCreateContext or whatever, rather than loaded
explicitly by libglx. The server still needs to be a window system for the
5000 GLX applications that already exist, and we'll still want to be able to
do accelerated indirect GLX.
Since I haven't looked at the code in a month, can someone remind me
why X needs to directly access libdrm and not use a DRI interface? For
example the whole drmOpen sequence of where X searches for and loads
DRM drivers would just go away if we let the OS automatically load the
drivers based on PCI IDs. The current Linux DRM driver supports this.
Several of the DDXes and libdri call into libdrm. I don't have a good
enumeration of why they do that though.
Even in an X-on-GL world, you need a server process, and that server will want
to act as a GL renderer for indirect clients. Fixing libglx to use a DRI
driver as the renderer (instead of GLcore) should in fact make an Xgl server
Common X server DDX calls to libdrm are:
map adding / removal
agp alloc / free / bind / unbind /map /unmap
irq enabling / disabling
locking / unlocking
drmCommandWrite / Read for vendor-specific functionality.
Some of these, but not all, can be done by the drm itself, as Jon
xorg mailing list