> I've been thinking about going about all this in a different
> way. Instead
> of loading up dlls/ddraw with driver-dependent code, perhaps we should
> consider driver separation not only in dsound (like it's done
> now, with
> IDsDriver in the wineoss driver), and like I want to do with dinput
> (IDiDriver in winmm's joystick driver etc), but also in ddraw?
>
> So the x11drv (and any future graphics drivers) would export a
> IDdDriver-or-whatever-it's-called COM interface, that dlls/ddraw could
> then build upon, just like in windoze. All the DGA, DXGrab,
> and GLX code
> would then have to be moved into the x11drv, obviously, so
> it'd be a lot
> of work, but it'd certainly give us some advantages as well...
Good idea (almost).
However I don't think we should put DirectX related X11 stuff
directly in x11drv it bloats it to much. Most applications don't
use DirectX so it shouldn't need to load it in memory or even
require its presence on the harddisk.
Why not have some kind of X11 subdriver (ddraw_x11drv or something)
that are allowed to access the internals in the x11drv through
a special API instead?
This makes separate upgrading of the different dlls much easier
when we have released a stable version.
Perhaps this will also help you (Transgaming) to easier be able
to distribute your special version in _binary_ form. Just distribute
your own libddraw.so and libddraw_x11drv.so or perhaps even
just libddraw_x11drv.so. If you implement everything in the x11drv
it will be somewhat harder to keep in sync since the x11drv might
have changed in the main tree.
