[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Suggestion



> On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote:
> > It's not the compiled code which has to match between DRI and DRM,
> > just the interface.  I'm using a DRM module compiled along with my
> > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so
> > which came in the X packages.  After all, it all goes through a /dev/
> > interface - if the compilation had to match, then you'd have to recompile
> > *all* your binaries whenever you recompile your kernel, and that makes
> > absolutely no sense whatsoever.
> > 
> > And since DRM is already distributed as part of the kernel, there's really
> > no point in putting it in a separate package. :
hmm I just got something wrong :
 I was not really sure (I know that now) where dri/drm modules modules
came from ...
there are kernel modules from my 2.4.0test6 kernel called "drm.o"
"mga.o" "mga_drv.o" in /lib/modules.../drm/ and in the xserver-xfreee86
package there are
some files called "/usr/X11R6/lib/modules/dri/mga_dri.so" and
"/usr/X11R6/lib/modules/drivers/mga_drv.o".
So I got confused what object file is what.
I thought that it is redundant (mga_drv.o) .
After all dri didnt work for me although I have a
/proc/dri/0/  directory ...
X said "(EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 1.0.0,
expected 2.0.x)
.  Disabling DRI." so I thought that there was a modules version
mismatch ...
I read the DRI Howto which said :"3D hardware acceleration requires a
DRI kernel module that's specific to your graphics hardware. 

The DRI kernel module version must exactly match your running kernel
version. Since there are so many versions of the kernel, it's difficult
to provide precompiled kernel
modules. "

Maybe I dont need to enable drm in my kernel because X brings its own
modules, but then they must match my kernel version, so I thought a
seperate DRI package would be great.

maybe I get it working, then I know that I was totally wrong and the
current way of packing X is great. (Of course otherwise it is also great
) 

> 
> Thanks for the good counterargument.
Yes thanks a lot.
> 
> I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules.
> If they aren't really X server modules, then they don't belong in that
> directory (maybe /usr/lib/xlibmesa3 ?).  Should I ask upstream?
> 
> > > Also very interresting, the mesa package (xlibmesa3) must also be
> > > "compileable" whitout 
> > > compiling the whole X.
> > 
> > Why?  xlibmesa3 is part of the X server.  It's based on Mesa, but it's not
because of assembler optimising (not every CPU understands 3DNow! or MMX
or even Pentium assembler.
> > Mesa.
> 
> Well, actually it is.  It's just not generally the exact same version of
> Mesa that the Mesa developers have released.  (That and the fact that the X
> build doesn't create libGLU yet.)
> 
> > Isn't the current X server autodetection stuff good enough?
> 
> Actually, it isn't.  But I've written a program called "dexter" (which
> replaces the old xserver-configure script) which does the prompting this
> person wanted to see.
cool ! 
> 
> > I'm sure there'll eventually be (if there isn't already) XF86Setup for
> > XFree 4, which will let people graphically mangle their conffiles once
> > again...
> 
> Yes, xf86cfg, but it is not complete yet.
I was thinking of a config tool to create the X make files (*.cf *.def
etc)
to be able to get a running ( mine isn't running yet ) and optimised X
server and dri modules as well as mesa librarys.

I am sorry if I got some of these things mixed up.
thanks for the competent and quick answer.
regards, 

	Sven Heyll





Reply to: