Re: [Dri-devel] xf86cfg build problems (was: Re: Wiki Update)
On Tuesday 20 April 2004 07:34, Felix Kühling wrote: Better yet, set #define BuildXFree86ConfigTools NO in xc/config/cf/host.def. This should probably be made the default setting. Noted, thanks. I took a quick look for the relevant option when I first added that text, but must have missed it. - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] Warning message cleanup
All drivers except savage emit the Direct rendering disabled message as an
informational message; savage makes it an error. Technically it's not an
error, since the server can continue, but it should probably be at least a
warning. This would make troubleshooting easier, because users know to look
for lines with a (WW) or (EE) on them.
Attached patch makes this message a warning across all drivers.
- ajax
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/atiscreen.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/atiscreen.c,v
retrieving revision 1.3
diff -u -r1.3 atiscreen.c
--- xc/programs/Xserver/hw/xfree86/drivers/ati/atiscreen.c 12 Apr 2004 04:45:20 - 1.3
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/atiscreen.c 20 Apr 2004 00:03:27 -
@@ -563,7 +563,7 @@
Direct rendering enabled\n);
} else {
/* FIXME: Release unused offscreen mem here? */
- xf86DrvMsg(pScreenInfo-scrnIndex, X_INFO,
+ xf86DrvMsg(pScreenInfo-scrnIndex, X_WARNING,
Direct rendering disabled\n);
}
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c,v
retrieving revision 1.37
diff -u -r1.37 r128_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c 12 Mar 2004 21:22:52 - 1.37
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c 20 Apr 2004 00:03:31 -
@@ -2466,7 +2466,7 @@
if (info-directRenderingEnabled) {
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering enabled\n);
} else {
- xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering disabled\n);
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Direct rendering disabled\n);
}
#endif
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.86
diff -u -r1.86 radeon_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 29 Mar 2004 14:55:11 - 1.86
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 20 Apr 2004 00:03:37 -
@@ -4820,7 +4820,7 @@
}
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering enabled\n);
} else {
- xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering disabled\n);
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Direct rendering disabled\n);
}
#endif
Index: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c,v
retrieving revision 1.47
diff -u -r1.47 i810_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c 23 Oct 2003 02:23:30 - 1.47
+++ xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c 20 Apr 2004 00:03:40 -
@@ -2187,7 +2187,7 @@
if (pI810-directRenderingEnabled) {
xf86DrvMsg(pScrn-scrnIndex, driFrom, Direct rendering enabled\n);
} else {
- xf86DrvMsg(pScrn-scrnIndex, driFrom, Direct rendering disabled\n);
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Direct rendering disabled\n);
}
pScreen-SaveScreen = I810SaveScreen;
Index: xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c,v
retrieving revision 1.39
diff -u -r1.39 mga_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c 23 Oct 2003 02:23:31 - 1.39
+++ xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c 20 Apr 2004 00:03:43 -
@@ -3461,7 +3461,7 @@
if (pMga-directRenderingEnabled) {
xf86DrvMsg(pScrn-scrnIndex, driFrom, Direct rendering enabled\n);
} else {
-xf86DrvMsg(pScrn-scrnIndex, driFrom, Direct rendering disabled\n);
+xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Direct rendering disabled\n);
}
if (pMga-DualHeadEnabled pMga-SecondCrtc == FALSE)
pMgaEnt-directRenderingEnabled = pMga-directRenderingEnabled;
Index: xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c,v
retrieving revision 1.22
diff -u -r1.22 savage_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c 26 Mar 2004 22:20:40 - 1.22
+++ xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c 20 Apr 2004 00:03:48 -
@@ -2715,7 +2715,7 @@
if (psav-directRenderingEnabled) {
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering enabled\n);
} else {
-xf86DrvMsg(pScrn-scrnIndex, X_ERROR, Direct rendering disabled\n);
+xf86DrvMsg(pScrn-scrnIndex
Re: [Dri-devel] Questions about current status of DRI
On Saturday 17 April 2004 20:19, Vladimir Dergachev wrote: 4. Are there any examples of user-space applications accessing DRM, the same way Mesa driver does, but (hopefully) simpler ? I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. tests/drmstat.c in the drm/ module perhaps? (It strikes me that those won't build at all right now since they've been moved...) - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI CVS with X.org
I've successfully installed the various libraries and modules from DRI CVS on top of an X.org build, and it appears to work. (No great surprise that they're binary compatible still, I suppose.) Instructions are on the Building page on the wiki, along with suitably scary warning text; I probably missed something in the process so corrections are welcomed. It strikes me that this is probably a good thing for the Long Slow Decoupling of DRI from the X server, and that the given X.org instructions ought to work for XFree86 users as well. This is great, because it means a) users don't clobber their X libs and server binary when installing DRI CVS, and b) DRI doesn't need to be synced against some other X server tree nearly as much. Everyone wins. To that end I'm working on a shell script that would automate this minimalist install process, along with some magic to make it play nicely with Gentoo's OpenGL switcher (and any other OS- or distro-specific hooks). Any interest in seeing this committed to CVS? - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx snapshots
On Thursday 01 April 2004 19:24, Fryderyk Dziarmagowski wrote: Hello, I got following problem with tdfx snapshots: [EMAIL PROTECTED] fritz]$ LIBGL_DEBUG=1 glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/tdfx_dri.so failed (/usr/X11R6/lib/modules/dri/tdfx_dri.so: undefined symbol: _mesa_init_driver_functions) libGL error: unable to find driver: tdfx_dri.so TIA for any help, regards, tdfx is broken at the moment. If you apply the patches I posted here: http://marc.theaimsgroup.com/?l=dri-develm=107940633518998w=2 then it will be marginally less broken; basic polygons will work but textures will not. I believe the texture breakage was a result of the DRI transition from Mesa 5.0.2 to 5.1 [1]; therefore in order to get a working tdfx driver right now, you'd need to find a snapshot from before December 9 2003, or alternatively compile a DRI CVS checkout from that date (following the old build instructions, which are basically just 'cvs co make World make install'). I'm not entirely clear on _how_ 5.1 broke texturing; I expect that my battle plan will be to step through the changes one commit at a time, which doesn't sound very fun. Clues, speculation, and conspiracy theories would be welcomed. - ajax [1] - Eric posted some test results after the newmesa merge that indicate that tdfx broke in the process: http://marc.theaimsgroup.com/?l=dri-develm=107104443215443w=2 . The testing I've done agrees with this; DRI with 5.0.2 works, DRI with 5.1 does not. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On Wednesday 31 March 2004 04:48, Keith Whitwell wrote: I've committed most of this (where it didn't clash with changes I've already made). The build seems to work for me now, here. Let me know what happens on your end. Keith Builds fine here, including radeon and r200. Thanks. (tdfx still needs patching for COMMONOBJS and USE_NEW_INTERFACE, but those are runtime not buildtime.) - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa reshuffling breaks DRI compile
On Tuesday 30 March 2004 02:27, Keith Whitwell wrote:
Hmm. Those new breakages were my fault... Sorry about that. It looks like
Ian has committed some changes to address my breakage - can you try again
see?
Ian's commit only touched some Imakefiles, which is not what's going on here.
r{200,adeon}_context.h define struct dynfn as:
struct dynfn {
struct dynfn *next, *prev;
int key[2];
char *code;
};
but t_context.h now has this:
struct dynfn {
struct dynfn *next, *prev;
int key;
char *code;
};
I haven't looked at the codegen code much so I'm not sure what path to take.
- ajax
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On Tuesday 30 March 2004 16:52, Brian Paul wrote: CVSROOT: /cvs/mesa Module name: Mesa Repository: Mesa/src/mesa/main/ Changes by: [EMAIL PROTECTED] 04/03/30 14:52:00 Log message: these files now live in the shader directory Removed files: Mesa/src/mesa/main/: nvfragparse.c nvfragparse.h nvfragprog.h nvprogram.c nvprogram.h nvvertexec.c nvvertexec.h nvvertparse.c nvvertparse.h nvvertprog.h This breaks the DRI build: s_aatriangle.c:37:24: nvfragprog.h: No such file or directory Patch attached, which adds src/mesa/shader everywhere it's needed. This is a bit heavy-handed; would it be better to factor $MESA_INCLUDES up to a higher Imakefile? - ajax --- xc/lib/GL/mesa/array_cache/Imakefile 2004-03-30 19:16:02.0 -0600 +++ xc/lib/GL/mesa/array_cache/Imakefile 2004-03-30 19:16:38.0 -0600 @@ -45,6 +45,7 @@ -I$(MESASRCDIR)/src/mesa/array_cache \ -I$(MESASRCDIR)/src/mesa/glapi \ -I$(MESASRCDIR)/src/mesa/math \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/include \ -I../../../include -I$(XINCLUDESRC) --- xc/lib/GL/mesa/drivers/dri/common/Imakefile.inc 2004-03-30 19:35:01.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/common/Imakefile.inc 2004-03-30 19:34:08.0 -0600 @@ -32,6 +32,7 @@ COMMON_MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/../common \ -I$(MESASRCDIR)/include --- xc/lib/GL/mesa/drivers/dri/ffb/Imakefile.inc 2004-03-30 19:16:38.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/ffb/Imakefile.inc 2004-03-30 19:16:50.0 -0600 @@ -30,6 +30,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/ffb --- xc/lib/GL/mesa/drivers/dri/gamma/Imakefile.inc 2004-03-30 19:16:50.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/gamma/Imakefile.inc 2004-03-30 19:17:02.0 -0600 @@ -31,6 +31,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/gamma --- xc/lib/GL/mesa/drivers/dri/i810/Imakefile.inc 2004-03-30 19:17:02.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/i810/Imakefile.inc 2004-03-30 19:17:09.0 -0600 @@ -31,6 +31,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/i810 --- xc/lib/GL/mesa/drivers/dri/i830/Imakefile.inc 2004-03-30 19:17:09.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/i830/Imakefile.inc 2004-03-30 19:17:20.0 -0600 @@ -31,6 +31,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/i830 --- xc/lib/GL/mesa/drivers/dri/mga/Imakefile.inc 2004-03-30 19:17:20.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/mga/Imakefile.inc 2004-03-30 19:17:27.0 -0600 @@ -31,6 +31,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/mga --- xc/lib/GL/mesa/drivers/dri/r128/Imakefile.inc 2004-03-30 19:17:27.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/r128/Imakefile.inc 2004-03-30 19:17:34.0 -0600 @@ -32,6 +32,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/r128 --- xc/lib/GL/mesa/drivers/dri/r200/Imakefile.inc 2004-03-30 19:17:34.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/r200/Imakefile.inc 2004-03-30 19:17:39.0 -0600 @@ -32,6 +32,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common \ -I$(MESADRVSRCDIR)/r200 --- xc/lib/GL/mesa/drivers/dri/radeon/Imakefile.inc 2004-03-30 19:17:39.0 -0600 +++ xc/lib/GL/mesa/drivers/dri/radeon/Imakefile.inc 2004-03-30 19:17:46.0 -0600 @@ -32,6 +32,7 @@ MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ -I$(MESASRCDIR)/src/mesa/main \ -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/shader \ -I$(MESASRCDIR)/include \ -I$(MESADRVSRCDIR)/common
[Dri-devel] latent Xaw dependency
xc/programs/Xserver/hw/xfree86/xf86cfg/accessx.c has a dependency on Xaw:
#include X11/Xaw/Command.h
#include X11/Xaw/Form.h
#include X11/Xaw/Label.h
#include X11/Xaw/Scrollbar.h
#include X11/Xaw/Toggle.h
...
There's an xc/lib/Xaw directory in CVS but it's empty, which means the user
needs to have the Xaw headers installed already.
accessx.c is part of xf86cfg. Is there any reason for us to build any
programs besides glx{gears,info}, xdriinfo, (maybe) the server binary itself?
There's several ways to fix this obviously, either bring back the Xaw headers,
stop building useless binaries, or just document the need for the headers on
the Building page. #3 is probably easiest.
- ajax
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] latent Xaw dependency
On Friday 26 March 2004 21:47, Robert F Merrill wrote: ajax wrote: There's several ways to fix this obviously, either bring back the Xaw headers, stop building useless binaries, or just document the need for the headers on the Building page. #3 is probably easiest. - ajax Why do we need to build glxgears and glxinfo? And is the server binary really necessary? Why do we build libexpat and libfreetype? libxdmcp, libXv? glx* make sense to build; the DRI/Mesa combo implements GLX, GLX utilities are therefore in the right package. The others make varying amounts of sense. Really there ought to be GL binding modules for the various X (or Cairo, or whatever) servers, parallel to the way DRM has shared and OS-dependent parts, and no server needs gets built by the DRI tree at all. Until that happens, DRI more or less needs to provide a server binary somehow. Which drags in all sorts of other crap. FreeType, xdmcp, and Xv are probably needed to make the resultant server binary something that people would actually use. expat, as I understand it, is needed in the DRI drivers themselves for the XML configuration files. Xaw, on the other hand, is needed only to make this one utility program build - one that properly belongs bundled with some other package anyway. A quick bit of find/grep magic reveals that xf86cfg is the only component with any Xaw dependency. It's pretty useless, the user probably already has it if they want it, no one ever uses it, and we haven't put any changes into it so it's pointless to maintain a copy. I'm in favor of just blowing it away personally, but if that makes life harder for whoever imports the DRI into a given X server package, then documenting the need for the headers is fine too. I'm all for pruning the tree, but one step at a time is better. - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 14:06, ajax wrote: No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. Added a few to the list, mostly things I've had trouble with while getting tdfx to work again. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... Which reminds me. Brian, you'd said in: http://marc.theaimsgroup.com/?l=dri-develm=107099482602285w=2 that DRI builds should happen against a tagged Mesa branch. Currently the Building page tells people to build against HEAD. I know that's not good, but is that branch still the officially-blessed branch for stable builds? - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Friday 19 March 2004 12:26, Brian Paul wrote: I figured people doing driver development would prefer to work on a stable Mesa branch, but it hasn't panned out that way. I guess I don't feel too strongly either way. I don't think anyone's checked in any DRI driver changes to the stable mesa_6_0_branch branch so I'm not sure what state it's in. -Brian Well right now HEAD doesn't work for at least i810 and probably some others. I'm not so much concerned for the developers as for the users who just want to download it and have it work. Telling them to build against the stable branch (like (edit edit edit) the docs now say) should help. I hope. I suppose the next user to wander into #dri and ask me, gets to be the guinea pig. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 05:12, Felix Kühling wrote: dri branches will also need to apply this patch I don't like that. Can branches still keep their own copy of the old DRM? I'm particulary thinking of the s3virge branch which is unmaintained at the moment. I'm not sure if it even builds, but if it does it would be nice to keep it that way until someone picks it up. I just checked. It doesn't. make[6]: *** No rule to make target `../shared/at_scancode.c', needed by `at_scancode.c'. Stop. etc. However, Jon has done the right thing by saying this is what branches need to do to get working again. They shouldn't need to patch _now_, but knowing what needs to be done in the future makes it possible to revive sleeping branches. I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 13:03, Keith Whitwell wrote: I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. This seems reasonable to me... Thanks for taking this on. No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] tdfx build fixes and driinterface conversion
The first patch (against the Mesa tree) fixes tdfx_screen.c to use the new
interface. The second patch (against the DRI tree) fixes the Imakefilery to
use the new interface and link against the common objects.
Without these two tdfx is completely broken. With them, it works as well as
it did before driinterface was merged (which for me means textured apps are
hosed but glxgears works fine). That's next on my chopping block. I tested
this on 16-bit and 24-bit depths.
Comments are welcome. I don't particularly like how this duplicates loops in
*_dri.c and *_screen.c. I'd like to see a shared visual config table defined
in a header somewhere so we don't have to touch multiple places, but I
suspect that'd get ugly quick.
Index: src/mesa/drivers/dri/tdfx/tdfx_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/tdfx/tdfx_screen.c,v
retrieving revision 1.2
diff -u -r1.2 tdfx_screen.c
--- src/mesa/drivers/dri/tdfx/tdfx_screen.c 8 Dec 2003 17:14:47 - 1.2
+++ src/mesa/drivers/dri/tdfx/tdfx_screen.c 16 Mar 2004 01:37:04 -
@@ -316,6 +316,129 @@
.SwapBuffersMSC = NULL
};
+#ifdef USE_NEW_INTERFACE
+/*
+ * new interface code, derived from radeon_screen.c
+ * XXX this may still be wrong
+ */
+static PFNGLXCREATECONTEXTMODES create_context_modes = NULL;
+
+static __GLcontextModes *tdfxFillInModes(unsigned pixel_bits,
+ unsigned depth_bits,
+ unsigned stencil_bits,
+ GLboolean have_back_buffer)
+{
+ __GLcontextModes *modes;
+ __GLcontextModes *m;
+ unsigned num_modes;
+ unsigned vis[2] = { GLX_TRUE_COLOR, GLX_DIRECT_COLOR };
+ unsigned deep = (depth_bits 17);
+ unsigned i, db, depth, accum, stencil;
+
+ /* Right now GLX_SWAP_COPY_OML isn't supported, but it would be easy
+ * enough to add support. Basically, if a context is created with an
+ * fbconfig where the swap method is GLX_SWAP_COPY_OML, pageflipping
+ * will never be used.
+ */
+
+ num_modes = (depth_bits == 16) ? 32 : 16;
+
+ modes = (*create_context_modes)(num_modes, sizeof(__GLcontextModes));
+ m = modes;
+
+ for (i = 0; i = 1; i++) {
+ for (db = 0; db = 1; db++) {
+ for (depth = 0; depth = 1; depth++) {
+ for (accum = 0; accum = 1; accum++) {
+ for (stencil = 0; stencil = !deep; stencil++) {
+ if (deep) stencil = depth;
+ m-redBits = deep ? 8 : 5;
+ m-greenBits = deep ? 8 : 6;
+ m-blueBits = deep ? 8 : 5;
+ m-alphaBits = deep ? 8 : 0;
+ m-redMask = deep ?0xFF00 :0xF800;
+ m-greenMask = deep ?0x00FF :0x07E0;
+ m-blueMask = deep ?0xFF00 :0x001F;
+ m-alphaMask = deep ? 0x00FF : 0;
+ m-rgbBits = m-redBits + m-greenBits +
+ m-blueBits + m-alphaBits;
+ m-accumRedBits = accum ? 16 : 0;
+ m-accumGreenBits = accum ? 16 : 0;
+ m-accumBlueBits = accum ? 16 : 0;
+ m-accumAlphaBits = accum ? 16 : 0;
+ m-stencilBits = stencil ? 8 : 0;
+ m-depthBits = deep
+ ? (depth ? 24 : 0)
+ : (depth ? 0 : depth_bits);
+ m-visualType = i ? GLX_TRUE_COLOR
+ : GLX_DIRECT_COLOR;
+ m-renderType = GLX_RGBA_BIT;
+ m-drawableType = GLX_WINDOW_BIT;
+ m-rgbMode = GL_TRUE;
+ m-doubleBufferMode = db ? GL_TRUE : GL_FALSE;
+ if (db)
+ m-swapMethod = GLX_SWAP_UNDEFINED_OML;
+ m-visualRating = ((stencil !deep) || accum)
+ ? GLX_SLOW_CONFIG
+ : GLX_NONE;
+ m = m-next;
+ if (deep) stencil = 0;
+ }
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
+/**
+ * This is the bootstrap function for the driver. libGL supplies all of the
+ * requisite information about the system, and the driver initializes itself.
+ * This routine also fills in the linked list pointed to by \c driver_modes
+ * with the \c __GLcontextModes that the driver can support for windows or
+ * pbuffers.
+ *
+ * \return A pointer to a \c __DRIscreenPrivate on success, or \c NULL on
+ * failure.
+ */
+void * __driCreateNewScreen( Display *dpy, int scrn, __DRIscreen *psc,
+ const __GLcontextModes * modes,
+ const __DRIversion * ddx_version,
+ const __DRIversion * dri_version,
+ const __DRIversion * drm_version,
+ const __DRIframebuffer * frame_buffer,
+ drmAddress pSAREA, int fd,
+ int internal_api_version,
+ __GLcontextModes ** driver_modes )
+{
+ __DRIscreenPrivate *psp;
+
+ psp = __driUtilCreateNewScreen(dpy, scrn, psc, NULL,
+ ddx_version, dri_version, drm_version,
+ frame_buffer, pSAREA, fd,
+ internal_api_version, tdfxAPI);
+
+ create_context_modes = (PFNGLXCREATECONTEXTMODES)
+ glXGetProcAddress((const GLubyte *)__glXCreateContextModes);
+
+ if (create_context_modes != NULL) {
+ /* divined from tdfx_dri.c, sketchy */
+ TDFXDRIPtr dri_priv = (TDFXDRIPtr) psp-pDevPriv;
+ int bpp = (dri_priv-cpp 2) ? 24 : 16;
+
+ /* XXX i wish it
[Dri-devel] tdfx breakage (patch included)
The tdfx_dri.so generated by the trunk doesn't include some of the common driver code. It will build, but _mesa_init_driver_functions() is undefined in the resulting library, so the dlopen fails and direct rendering is disabled. The attached patch fixes this. --- lib/GL/mesa/drivers/dri/tdfx/Imakefile.orig 2004-03-10 08:36:00.252328096 -0600 +++ lib/GL/mesa/drivers/dri/tdfx/Imakefile 2004-03-10 08:36:18.930488584 -0600 @@ -48,7 +48,7 @@ SRCS = $(TDFXSRCS) OBJS = $(DRIOBJS) $(DRMOBJS) $(COREMESAOBJS) \ - $(MESA_ASM_OBJS) $(TDFXOBJS) + $(MESA_ASM_OBJS) $(COMMONOBJS) $(TDFXOBJS) REQUIREDLIBS = MathLibrary $(LDPRELIB) $(GLXLIB) $(XONLYLIB) ExpatLibrary
