[EMAIL PROTECTED] wrote:
>
> At Fri, 08 Jun 2001 07:04:31 -0600, Brian Paul <[EMAIL PROTECTED]> wrote:
>
> >
> >[EMAIL PROTECTED] wrote:
> >>
> >> Just wondering if anyone else saw something like this unresolved symbol
> >> in their X11 logs:
> >>
> >> (II) TDFX(0): Primary V_BIOS segment is: 0xc000
> >> (II) TDFX(0): VESA BIOS detected
> >> (II) TDFX(0): VESA VBE DDC supported
> >> Symbol DRIMoveBuffersHelper from module /usr/X11R6/lib/modules/drivers/tdfx_drv.o
> >> is unresolved!
> >> (==) TDFX(0): Write-combining range (0xe8000000,0x4000000)
> >> (II) TDFX(0): Changing back offset from 0x01aff000 to 0x01afe000
> >> (II) TDFX(0): Textures Memory 22.83 MB
> >>
> >> Haven't tried DRI yet (forgot, sorry), but without DRI i am in X and
> >have
> >> no problems.
> >>
> >> I am using the Linux-ix86-glibc21 X11 4.1.0 right off of ftp.xfree86.org,
> >> clean install (removed old X11) and the DRI drivers that come with
> >it.
> >> As for DRM I am using this along with kernel 2.4.4:
> >>
> >> [drm] Initialized tdfx 1.0.0 20010216 on minor 0
> >>
> >> and of course libglide3 from the dri.sourceforge.net resources page.
> >>
> >> Will update when i try DRI..
> >>
> >> Free, encrypted, secure Web-based email at www.hushmail.com
> >
> >
> >Are you loading the DRI X server extension?
> >
> >That is, does the "Module" section in your XF86Config-4 file have
> >Load "dri"?
>
> Yeah, that's what it was: missing Load "dri" (because at first I wanted
> to give xinerama a try, but without dri).
>
> Since I am on the subject:
> DRI worked fine in direct and indirect modes with Voodoo5.
> I also had much better results with using 2 cards on this system:
> Voodoo5 and Trident TGUI9680/9660 (not sure exactly because i specify chipset
> 9660 and then the Xserver says it found 9680.. weird). Using a dual screen
> layout (not Xinerama of course), i was able to get direct rendering on the
> V5 head and indirect on the Trident head. Of course being "rough" with the
> setup will cause it to crash and burn (lockup entire machine). I was being
> rough by CTRL_ALT_+/- while Quake3 was running in a window on the V5 head
> :) and some other tests.
> Anyways, I know that is not officially supported, just wanted to let people
> know it's getting better :)
David Dawes and I have done a bit of work on multihead support recently
(esp the tdfx driver). So multihead should be better in the not-too-distant
future.
> Since we are on the subject of modules, could you explain:
> how come you don't have GLcore loading? Just not going to use indirect/software
> rendering on your end ? (if I recall correctly from the PI docs I read,
> that's what it's used for).
>
> Does it matter if I put it in there, even though I will use Direct Rendering
> for my apps ?
The GLcore module is loaded as a submodule by the glx module so there's
no need to list it in your XF86Config file.
This happens in the xc/programs/Xserver/GL/glxmodule.c file:
static pointer
glxSetup(pointer module, pointer opts, int *errmaj, int *errmin)
{
static Bool setupDone = FALSE;
pointer GLcore = NULL;
#ifdef GLX_USE_SGI_SI
char GLcoreName[] = "GL";
#else
char GLcoreName[] = "GLcore";
#endif
LoadExtension(&GLXExt, FALSE);
/* Wrap the init visuals routine in micmap.c */
GlxWrapInitVisuals(&miInitVisualsProc);
/* Make sure this gets wrapped each time InitVisualWrap is called. */
miHookInitVisuals(NULL, GlxWrapInitVisuals);
GLcore = LoadSubModule(module, GLcoreName, NULL, NULL, NULL, NULL,
errmaj, errmin);
if (!GLcore)
ErrorF("Cannot load the GL core library: %s\n", GLcoreName);
/* Need a non-NULL return value to indicate success */
return GLcore;
}
-Brian
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
