On Thu, Mar 28, 2002 at 09:31:40AM +0000, Alan Hourihane wrote: >On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
>Also, we should be able to hide the type in the Linux os support and >not need to pass this ? > >I've just taken a closer look at the xf86drmRadeon.c code, and in >drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > >Going down this road though, we'll be pushing that back into the 2d/3d code >which I don't think is the right way to go. > >I'm thinking more of Jeff's solution now, and what we could do..... > >If we take a minimalist xf86drm.c which makes the libdrm.a loadable >module. Then within xf86drm.c we identify which sub-drm module to >load (i.e. the driver's libradeon_drm.a - or something like that) and >load it. For the *BSD's this code is a symlink from the Linux directory. I'm losing track of what the goal was with the changes. If it was to remove hw-specifics from the libdrm.a module, then I think Jeff's idea of pushing them into a separate HW-specific module is worth looking at. By doing this, it might even be feasible to make libdrm.a part of the (built-in) OS-support layer. Stepping back a bit, the current model puts different types of dependencies in different places. The XFree86 video driver module contains HW dependencies, but should have no OS dependencies. The libdrm.a module contains both HW and OS dependencies. I guess the aim is to separate that into the HW-dependent and HW-independent pieces? One problem I had with simply changing the libdrm.a interfaces is that it doesn't succeed in making that separation. Something in libdrm.a still needs to know how to translate a HW-specific command into whatever is appropriate for the OS. I.e, there's nothing conceptually different between drmRadeonCPStop(args) and drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP can be passed transparently to the HW+OS specific component that will actually do the requested operation. With Jeff's suggestion there would be several components: video driver module (HW specific, OS independent) core libdrm module (HW independent, OS specific, so part of core server?) HW libdrm module (HW specific, OS specific) The question this raises is what do we gain from this? What would actually be in the core libdrm module -- is there enough there to justify separating out the HW-specific parts? If the HW libdrm module could be made HW specific and OS independent, then that would be a big win, and it could even be moved into the video driver module in that case. This would simplify things to the point where the OS-specific parts are built-in to the X server and the HW specific parts are all in the video driver module. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
