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

Re: [tomlins@cam.org: DRI wth 2.2.18pre kernels]



Hi,  

Some info and feedback on DRI in 2.2.18pre.   Chip Salzenberg posted a patch 
for 2.2.18pre21 that upgrades drm to 2.0.0 levels.  This lets the G400 work 
with xf4 as is in woody.   Without this patch DRI does not work for G400s.

TIA,

Ed Tomlinson

On November 23, 2000 07:29 pm, Ed Tomlinson wrote:
> On November 23, 2000 06:38 pm, Zephaniah E. Hull wrote:
> > > Please don't send mail to Branden directly, questions such as this are
> >
> > much better suited for debian-x.
> >
> > > ----- Forwarded message from Ed Tomlinson <tomlins@cam.org> -----
> > > Hi,
> > >
> > > I do not know if this has been reported as a bug yet as the
> > > bugs.debian.org page does not seem to work...
> > >
> > > I have just upgraded to woody (worked but was a little painfull).  The
> > > major reason for this was to get to XF4 and get DRI and dualhead
> > > working with my matrox G400 MAX.  Well I can get everything going
> > > except that when drm is finally ready to enable DRI it fails since the
> > > version reported my mga.o is 1.0.0 and the xserver wants 2.0.0 or
> > > above.
> >
> > This is an upstream decision, I believe there are back port patches for
> > the DRM modules to 2.2.x kernels, however I am not positive.
> >
> > Also I believe that the current 2.2.x pre kernels from Alan Cox have an
> > up to date DRM module.
>
> Yes.  I am running 2.2.18pre21aa2 with agpgart and dri built from the stuff
> in pre21.  Problem is that the mga.o module it builds reports its version
> as 1.0.0 and the stuff in the debs expects 2.0.0.  This stops things dead. 
> Note ifs not as simple as hacking mga.o to report 2.0.0.  This will get dri
> enable but will not work (the xserver crashes when dri start).
>
> I have also tried the mga_drv.o from matrox.  This one lets dri enable but
> then libGL.o complains about the version.  The matrox version also messes
> up the card settings so a reqular framebuffer screen will not display
> correctly (a problem for matrox to fix...).
>
> > The only thing we (Debian) can do to fix this is try and make sure that
> > the kernel sources we package have the current DRM module patches.
>
> Understood.  Then consider this a heads up.  The 2.2.18 kernel has lots of
> nice goodies, usb, agpgart, dri, nfsv3.  IMVHO Its going to be a very
> popular kernel.  It would be a good idea to be ready to support this when
> it arrives. Suggest that 2.2.18pre23 be used as a model and packaged and
> the various accessories (like XF4) built to work with it.
>
> TIA,
> Ed Tomlinson
>
> > Zephaniah E. Hull.
> > (The Debian developer who somehow got the 3Dfx issues, even under
> > packages he does not maintain.)
> >
> > > Before I go through the pain of learning how to rebuild the
> > > package(s), will it work with dri 1.0.0 at all?  If so are you
> > > planning .debs for 2.2.18?  In any case if it will work with dri 1.0.0
> > > just what packages need to be rebuilt?  Do you have pointers to docs
> > > on just how to rebuild them?
> > >
> > > TIA,
> > > Ed Tomlinson <tomlins@cam.org>
> > >
> > > BTW xf86cfg fails here.  first it cannot detect my usb mouse correctly.
> > > Once I fixed the symlink in /dev it failed to autodetect the protocol
> > > needed.  It did write enought of an XF86Config to get X started after
> > > fixing the mouse up. Then, when started under X, it complained that the
> > > cards DB was not found.... On irc I was advised to try dexter.  Dexter
> > > will not generate anything but an 3.3.6 version file for me...  I did
> > > get it all working (manually) but thought the above might help.
>
> ----------------------------------------
> Content-Type: application/pgp-signature; charset="us-ascii";
> name="Attachment: 1"
> Content-Transfer-Encoding: 7bit
> Content-Description:
> ----------------------------------------



Reply to: