Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch] - dispatcher files
APIspec file gl*.py - Python API scripts
main/ - core Mesa sources
attrib.c
context.c
enable.c
...
CPU detection code
transform/ - was tnl
t_*.[ch]
X86/3Dnow code
math/ - math/vector routines
m_*.[ch]
swrast/ - s/w rasterization
s_*.[ch]
mmx_blend.S
swsetup/ - was swrast_setup
ss_*.[ch]
arraycache/ - vertex array stuff
ac_*.[ch]
drivers/
common/ - reusable driver code
and transform_dd/ files
x11/ - X11 (XMesa) driver
osmesa/ - OSMesa driver
swfbdev/ - software fbdev driver
radeon/ - DRI/fbdev driver
radeon-es/ - subset radeon fbdev driver
r200/ ...
mga/ - DRI/fbdev driver
windows/
beos/
ggi/
glide/ - was FX driver
dos/
dri/ - es dri code
Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset.
I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly.
My suggestion:
drivers/ common/ - reusable driver code and transform_dd/ files x11/ - X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/ - software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/ - dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/ - DRI/fbdev driver
Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on.
I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet.
I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers.
I guess I still don't see how an extra directory level addresses that.
This way all the things in drivers/ would be equivalent objects.
I guess I don't see this either. Help me out.
-Brian
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
