From: <uni...@sh...> - 2004-12-31 09:15:47
|
Adam Jackson wrote: >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 >design issue. > > > >>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 >simpler. > > > 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. Common X server DDX calls to libdrm are: Open Authentication 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 mentions. /Thomas >- ajax > > >------------------------------------------------------------------------ > >_______________________________________________ >xorg mailing list >xo...@li... >http://lists.freedesktop.org/mailman/listinfo/xorg > > |