From: Oliver F. <ki...@li...> - 2001-01-11 12:02:44
|
Brian Paul wrote: > > > > I am not sure if this is correct, since both programs report a > > "Voodoo4", while my friend has a Voodoo 5 card. I was able to trace > > this back to the Glide library (CVS snapshot 22-12-2000), which seems > > to detect only one chip on the card, even though it looks like there > > is support for up to four chips in the library. > > When Glide is updated for Voodoo5's second chip, the glGetString(GL_RENDERER) > call will report Voodoo5 instead of Voodoo4. Hmm, I thought with the tdfx-3-0-0 merge supports both chips now. I thought I remember someone saying (I think it was on the dri-users list some time ago) that he got about 1400 fps with gears -info which is pretty much twice what I get. I have another question about glide3 compiling with 3DNow!. When I compile glide with 3DNow! support DRI will be disabled because of an undefinded symbol (_trisetup_Default_win_nocull_invalid) in the glide library. Compiling glide without 3DNow! results in a library with 00031dc0 T _trisetup_Default_clip_nocull_invalid 00031dc0 T _trisetup_Default_clip_nocull_valid 00031dc0 T _trisetup_Default_win_nocull_invalid 00032120 T _trisetup_Default_win_nocull_valid Compiling with 3DNow! resulsts in 00031f80 T _trisetup_3DNow_clip_nocull_invalid 00031f80 T _trisetup_3DNow_clip_nocull_valid 00031f80 T _trisetup_3DNow_win_nocull_invalid 00032740 T _trisetup_3DNow_win_nocull_valid U _trisetup_Default_win_nocull_invalid U _trisetup_Default_win_nocull_valid With the _Default_ symbol undefined DRI gets disabled. Bye Oliver -- Oliver Feiler ki...@gm... http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2 http://www.lionking.org/~kiza/ |
From: Oliver F. <ki...@gm...> - 2001-02-07 09:52:31
|
Gilles May wrote: > > Well then you're luckier than me. Even X's DGA Testprogramm blanks my > screen and crashes the system. VMWare simply says that their DGA code > might or might not work with 4.0.x and "if there's a problem with DGA then > your X server doesn't support DGA". Somehow I'm happy I'm not the only > one with these problems. Anybody else? :) I just tried the DGA testprogram again, but it didn't really work. I'm sure it used to work at some point. The screen wents black and nothing seems to happen. According to the manpage the screens color should be changed for each keypress. However I can exit the program with 'q' and 'b' does the benchmark mentioned in the manpage. > > Btw. Considering the lack of documentation the programmers have I think the > job they do is excellent. Yes, I was really happy when I threw away the stuff 3DFX had on their linux page and downloaded a DRI CVS. :) Bye, Oliver -- Oliver Feiler ki...@gm... http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2 http://www.lionking.org/~kiza/ |
From: Oliver F. <ki...@li...> - 2001-02-09 14:30:30
|
Nathan Hand wrote: > On Wed, Feb 07, 2001 at 11:21:43PM +0000, Eduardo P?rez wrote: > > Hello TDFX Users ! > > > > I've got the latest drivers from the xfree86 devel branch (:pserver:an...@an...:/cvs) and Xv seems to work perfect ! > > > > I've got running: xine_0.3.7, smpeg-plaympeg_0.4.2-2 (libsdl1.1_1.1.7-3) (from debian unstable) and avifile-0.53.2 > > all with yuv planar support and yuv packed pixel with xawtv_3.30 > > > > Why there are more updated drivers in the xfree86 tree than in th dri tree ? > > Because 2d work goes on in the xfree86 tree, and 3d work goes on in the > dri tree. Every now and then there is a merge which syncs up all of the > changes between the two trees. Hmm, ok. I downloaded a XFree CVS and that seems to solve a 2D problems. However the tdfx DRI driver in the CVS does not compile and the DRI version I have (from Jan 20th) refuses to work and direct rendering is disabled. libGL error: 3dfx DRI driver expected DRI version 3.0.x but got version 3.1.0 Is there any way to get this to work together? If not the problem will solve itself with the next tree merge anyway right? Oliver -- Oliver Feiler ki...@gm... http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2 http://www.lionking.org/~kiza/ |
From: Philip W. <pg...@do...> - 2001-02-09 14:43:56
|
Today, Oliver Feiler wrote: >Nathan Hand wrote: >> On Wed, Feb 07, 2001 at 11:21:43PM +0000, Eduardo P?rez wrote: >> > Hello TDFX Users ! >> > >> > I've got the latest drivers from the xfree86 devel branch (:pserver:an...@an...:/cvs) and Xv seems to work perfect ! >> > >> > I've got running: xine_0.3.7, smpeg-plaympeg_0.4.2-2 (libsdl1.1_1.1.7-3) (from debian unstable) and avifile-0.53.2 >> > all with yuv planar support and yuv packed pixel with xawtv_3.30 >> > >> > Why there are more updated drivers in the xfree86 tree than in th dri tree ? >> >> Because 2d work goes on in the xfree86 tree, and 3d work goes on in the >> dri tree. Every now and then there is a merge which syncs up all of the >> changes between the two trees. > > Hmm, ok. I downloaded a XFree CVS and that seems to solve a 2D >problems. However the tdfx DRI driver in the CVS does not compile and the DRI >version I have (from Jan 20th) refuses to work and direct rendering is >disabled. > >libGL error: 3dfx DRI driver expected DRI version 3.0.x but got version 3.1.0 > > Is there any way to get this to work together? If not the problem will >solve itself with the next tree merge anyway right? Taking code from both DRI and XFree86 CVS is not a good plan (I've tried it). Your best bet is to choose which you would rather use at the moment and stick with that until a couple of days after the next merge (merging often breaks some stuff). You might be able to kludge something together by grabbing DRI CVS of a day or so after the last merge and praying, but I wouldn't recommend it. Regards, Philip Willoughby |
From: Nathan H. <na...@ma...> - 2001-02-09 14:48:05
|
On Fri, Feb 09, 2001 at 03:32:06PM +0100, Oliver Feiler wrote: > Nathan Hand wrote: > > On Wed, Feb 07, 2001 at 11:21:43PM +0000, Eduardo P?rez wrote: > > > Hello TDFX Users ! > > > > > > I've got the latest drivers from the xfree86 devel branch (:pserver:an...@an...:/cvs) and Xv seems to work perfect ! > > > > > > I've got running: xine_0.3.7, smpeg-plaympeg_0.4.2-2 (libsdl1.1_1.1.7-3) (from debian unstable) and avifile-0.53.2 > > > all with yuv planar support and yuv packed pixel with xawtv_3.30 > > > > > > Why there are more updated drivers in the xfree86 tree than in th dri tree ? > > > > Because 2d work goes on in the xfree86 tree, and 3d work goes on in the > > dri tree. Every now and then there is a merge which syncs up all of the > > changes between the two trees. > > Hmm, ok. I downloaded a XFree CVS and that seems to solve a 2D > problems. However the tdfx DRI driver in the CVS does not compile and the DRI > version I have (from Jan 20th) refuses to work and direct rendering is > disabled. The DRI CVS does not compile? What is the error message. > libGL error: 3dfx DRI driver expected DRI version 3.0.x but got version 3.1.0 Yes, the dri-trunk has 3.0.0, and the latest tdfx driver is 3.1.0 (some improvements to subimages). You are mix-and-matching versions here. You can't just install components of the DRI CVS and hope it works. This is likely you using /usr/X11R6/bin/XFree86 from XFree86 4.0.2 and tdfx_dri from DRI CVS. Make sure all components are from the same tree. > Is there any way to get this to work together? If not the problem will > solve itself with the next tree merge anyway right? Yup. -- The more I know about the WIN32 API the more I dislike it. It is complex and for the most part poorly designed, inconsistent, and poorly documented. - David Korn |
From: Oliver F. <ki...@li...> - 2001-02-09 15:15:45
|
Nathan Hand wrote: > > > > Hmm, ok. I downloaded a XFree CVS and that seems to solve a 2D > > problems. However the tdfx DRI driver in the CVS does not compile and the DRI > > version I have (from Jan 20th) refuses to work and direct rendering is > > disabled. > > The DRI CVS does not compile? What is the error message. No no. The tdfx driver from the _XFree CVS_ I just downloaded doesn't compile. I have this problem everytime. There is no Makefile in xc/xc/lib/GL/mesa/src/drv/tdfx and I can't find any way to compile it manually. DRI CVS always compiles fine. > > > libGL error: 3dfx DRI driver expected DRI version 3.0.x but got version 3.1.0 > > Yes, the dri-trunk has 3.0.0, and the latest tdfx driver is 3.1.0 (some > improvements to subimages). You are mix-and-matching versions here. You > can't just install components of the DRI CVS and hope it works. This is > likely you using /usr/X11R6/bin/XFree86 from XFree86 4.0.2 and tdfx_dri > from DRI CVS. Make sure all components are from the same tree. Well, it used to work with 4.0.2, But not with the CVS any more. But since the XFree CVS version works much better as far as 2D problems are concerned I think I'll stick with that for the moment and wait. Oliver -- Oliver Feiler ki...@gm... http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2 http://www.lionking.org/~kiza/ |
From: Nathan H. <na...@ma...> - 2001-02-09 15:29:32
|
On Fri, Feb 09, 2001 at 04:17:33PM +0100, Oliver Feiler wrote: > Nathan Hand wrote: > > > > > > Hmm, ok. I downloaded a XFree CVS and that seems to solve a 2D > > > problems. However the tdfx DRI driver in the CVS does not compile and the DRI > > > version I have (from Jan 20th) refuses to work and direct rendering is > > > disabled. > > > > The DRI CVS does not compile? What is the error message. > > No no. The tdfx driver from the _XFree CVS_ I just downloaded doesn't > compile. I have this problem everytime. There is no Makefile in > xc/xc/lib/GL/mesa/src/drv/tdfx and I can't find any way to compile it > manually. You need to run "make Makefiles". The XFree86 tree is a little crufty to build. Running "make World" from the root of the tree does all the setup you need, including building Makefiles and linking headers into place. The lib/GL directory is especially weird (it has no source but sucks source in from extras/Mesa when you run "make World"). If you already knew all this, please ignore me. > DRI CVS always compiles fine. Oh good :-) > > > libGL error: 3dfx DRI driver expected DRI version 3.0.x but got version 3.1.0 > > > > Yes, the dri-trunk has 3.0.0, and the latest tdfx driver is 3.1.0 (some > > improvements to subimages). You are mix-and-matching versions here. You > > can't just install components of the DRI CVS and hope it works. This is > > likely you using /usr/X11R6/bin/XFree86 from XFree86 4.0.2 and tdfx_dri > > from DRI CVS. Make sure all components are from the same tree. > > Well, it used to work with 4.0.2, But not with the CVS any more. But > since the XFree CVS version works much better as far as 2D problems are > concerned I think I'll stick with that for the moment and wait. I've just updated the DRI CVS trunk with the latest 2d tdfx driver in XFree86. I'm playing multiple mpegs with multiple 3d clients, no more crashes. Check it out and see if it solves your problems. -- The more I know about the WIN32 API the more I dislike it. It is complex and for the most part poorly designed, inconsistent, and poorly documented. - David Korn |
From: Oliver F. <ki...@li...> - 2001-02-09 17:58:34
|
Nathan Hand wrote: > > > > No no. The tdfx driver from the _XFree CVS_ I just downloaded doesn't > > compile. I have this problem everytime. There is no Makefile in > > xc/xc/lib/GL/mesa/src/drv/tdfx and I can't find any way to compile it > > manually. > > You need to run "make Makefiles". The XFree86 tree is a little crufty > to build. Running "make World" from the root of the tree does all the > setup you need, including building Makefiles and linking headers into > place. The lib/GL directory is especially weird (it has no source but > sucks source in from extras/Mesa when you run "make World"). > > If you already knew all this, please ignore me. Yes, I know it. :) But, the tdfx driver in xc/xc/lib/GL/mesa/src/drv/tdfx/ is not compiled in the XFree source tree. I just compiled 4.0.2 and there is no Makefile generated there. However the others, SIS, i850, mga, etc. are built. It works with the DRI tree. > > I've just updated the DRI CVS trunk with the latest 2d tdfx driver in > XFree86. I'm playing multiple mpegs with multiple 3d clients, no more > crashes. Check it out and see if it solves your problems. Wow, that did it. Everything works fine now. Now that was a real improvement. Thank you. :) Oliver -- Oliver Feiler ki...@gm... http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2 http://www.lionking.org/~kiza/ |
From: Mike P. <hei...@lo...> - 2001-02-13 00:18:43
|
> > > I'll poke around here and see if I can figure out what I'm doing wrong. > > > > There are other people having trouble, so you're not alone ;-) > > > > I'll keep looking too. > > I'm trying the LIBGL_DEBUG stuff now, to see if I missed something > earlier. Found it. Oh, I am so irritated. When I *first* build DRI, I did the X11R6-DRI thing. However, it was a hassle, and this is a slickable box, so I changed my mind and installed over /usr/X11R6 instead. I never wiped the -DRI directory. OK, fast forward to finally getting the Voodoo 3 set up. Since somehow my XF86Config got corrupted (don't ask, I don't know either), I just pulled the sample one from DRI's web page. It uses X11R6-DRI as the module path. So, I was effectively using a five-weeks-old version of DRI, and wondering why current bugfixes weren't working.... Ugh. Lesson learned, there IS no X11R6-DRI on my system anymore, so I won't get stung by it again. Thanks for the help, the fix looks like it's working after all. Descent 3, Myth 2, etc. are all working fine. This also fixed the Heroes 3 Xv issues (whee!), and I'm about to update from CVS to see if that will fix an weird overlay from the movie. Good job, guys. Sorry for raising a false alarm. (BTW, I *am* seeing the "missing strips" from the globe in SoF -- both the demo and the retail release.) -- Mike Phillips, hei...@lo... QA/Support, Loki Software, Inc. |
From: Nathan H. <na...@ma...> - 2001-02-13 00:43:46
|
On Mon, Feb 12, 2001 at 04:19:08PM -0800, Mike Phillips wrote: > > So, I was effectively using a five-weeks-old version of DRI, and > wondering why current bugfixes weren't working.... > > Lesson learned, there IS no X11R6-DRI on my system anymore, so I won't > get stung by it again. > > Thanks for the help, the fix looks like it's working after all. Descent > 3, Myth 2, etc. are all working fine. This also fixed the Heroes 3 Xv > issues (whee!), and I'm about to update from CVS to see if that will fix > an weird overlay from the movie. > > Good job, guys. Sorry for raising a false alarm. No worries. I've done the same thing myself. > (BTW, I *am* seeing the "missing strips" from the globe in SoF -- both > the demo and the retail release.) Yes, there are issues with SOF, which I can now reproduce (yay). -- The more I know about the WIN32 API the more I dislike it. It is complex and for the most part poorly designed, inconsistent, and poorly documented. - David Korn |
From: Ian D R. <id...@cs...> - 2001-06-05 20:45:06
|
> > In theory, yes. In practice? Not really. Sure, the odd patch is > > submitted, but that's about it. Not much else has come from the "open > > source community"... > > The fact that most of the interesting design discussions took place on closed > mailing lists didn't help a lot, I'm sure. > > It's slightly chicken and egg - without a strong external developer or two, > there was no impetus to take those discussions off the va/pi internal lists. I had the same problem with the paid-OSS project that I'm working on (http://oss.software.ibm.com/developerworks/projects/dlm). My group "solved" the problem by simply not having any internal mailing list. The only list is the external list. Shortly after we did that, the VP of Linux here decided that all OSS groups should/had to do the same. It seems to be working pretty well. Just my $0.02. -- I was actually quite pleased to see the Sonics win http://www.cs.pdx.edu/~idr game four of the 1996 NBA Finals...until I saw the USA Today headline that read, "Sweepless In Seattle." |
From: Alan C. <al...@lx...> - 2001-08-08 16:52:22
|
> I sent a patch to Linus and Alan this morning. Tweaked to allow either 4.0 or 4.1 DRM to be built (most folks need 4.0 still) and merged |
From: F. <jrf...@tu...> - 2003-03-19 12:07:54
|
On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: > An XFree86 bugzilla is now available at <http://bugs.xfree86.org/>. > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for > hosting, and the many developers who helped configure and test it. This is great news. I think a great job was done organizing the products and components. I know that the current policy on DRI is to post bugs on dri-users or dri-devel, but with XFree86 having a bug database is inevitable that people will eventually post bugs there too. Therefore what's the possibility of: - Setting up a general "owner" for DRI bugs, which probably would be dri...@li.... - automatically set the owner of DRI bugs, e.g., by the users adding a "DRI" keyword, or associating the "XFree86 Server"->"DRI" extension component. - Add the possibility to add comments to bugs via e-mail. Basically I would like to be possible that: - An user adds a bug concerning DRI - The owner is (either manually or automatically) set to dri...@li..., which receives the bug - Any developer on the dri-devel list which has an account on XFree86 Bugzilla can reply and that comment is added to the bug database. - Certain maintainence tasks (such as closing the bug, read an attachment) will require to use Bugzilla web interface, but bugzilla can be configured to remember our login, so it's straightforward. I would appreciate if the XFree86 and DRI developers considered this. José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: Philip B. <ph...@bo...> - 2003-03-19 19:35:51
|
On Wed, Mar 19, 2003 at 12:07:56PM +0000, José Fonseca wrote: > On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: > > An XFree86 bugzilla is now available at <http://bugs.xfree86.org/>. > > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for > > hosting, and the many developers who helped configure and test it. > > This is great news. I think a great job was done organizing the products > and components. > .... I dont get it. Why is this suddenly great news, when DRI could have been using sourceforge's bugtracking system all this time? I completely agree that using a real bugtracking system is what should be happening right now. However, it seems the decision to abandon that methodology was somehow made around 2001, judging by all the bug reports already sitting on http://sourceforge.net/tracker/?group_id=387&atid=100387 Someone with access should really go through those things, and clear out all the ones that have now been rendered(ahem) obsolete. |
From: Keith W. <ke...@tu...> - 2003-03-19 19:51:55
|
Philip Brown wrote: > On Wed, Mar 19, 2003 at 12:07:56PM +0000, Jos=E9 Fonseca wrote: >=20 >>On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: >> >>>An XFree86 bugzilla is now available at <http://bugs.xfree86.org/>. >>>Many thanks to Hewlett-Packard for supplying the hardware, netSweng fo= r >>>hosting, and the many developers who helped configure and test it. >> >>This is great news. I think a great job was done organizing the product= s >>and components. >>.... >=20 >=20 > I dont get it. Why is this suddenly great news, when DRI could have bee= n > using sourceforge's bugtracking system all this time? >=20 > I completely agree that using a real bugtracking system is what should = be > happening right now. >=20 > However, it seems the decision to abandon that methodology was somehow = made > around 2001, judging by all the bug reports already sitting on > http://sourceforge.net/tracker/?group_id=3D387&atid=3D100387 The sourceforge bug tracker is a broken pos. Keith |
From: Philip B. <ph...@bo...> - 2003-03-19 21:20:43
|
On Wed, Mar 19, 2003 at 07:52:00PM +0000, Keith Whitwell wrote: > [...] > The sourceforge bug tracker is a broken pos. Yet tens, if not hundreds, of people seem to have reported bugs successfully with it against dri. Even if the decision stands to no longer field new bugs there, it would still be nice if someone cleaned out the bugs there that are no longer relevant. |
From: Mike A. H. <mh...@re...> - 2003-03-20 02:25:20
|
On Wed, 19 Mar 2003, Philip Brown wrote: >> [...] >> The sourceforge bug tracker is a broken pos. > >Yet tens, if not hundreds, of people seem to have reported bugs >successfully with it against dri. Millions could report bugs using it potentially. That doesn't make it a good tool, nor does it make it one that is well suited to the specific task of tracking bugs for the DRI project. The DRI developers clearly think that it is crap, and that is the bottom line really, regardless of what anyone else thinks. I just happen to agree with them. ;o) >Even if the decision stands to no longer field new bugs there, it would >still be nice if someone cleaned out the bugs there that are no longer >relevant. Feel free. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Philip B. <ph...@bo...> - 2003-03-20 02:38:01
|
On Wed, Mar 19, 2003 at 09:31:41PM -0500, Mike A. Harris wrote: > On Wed, 19 Mar 2003, Philip Brown wrote: > >Even if the decision stands to no longer field new bugs there, it would > >still be nice if someone cleaned out the bugs there that are no longer > >relevant. > > Feel free. that requires both access/permissions to do so, and a working DRI system to validate/devalidate bugs. I have neither. |
From: F. <jrf...@tu...> - 2003-03-19 20:17:17
|
On Wed, Mar 19, 2003 at 11:38:30AM -0800, Philip Brown wrote: > On Wed, Mar 19, 2003 at 12:07:56PM +0000, José Fonseca wrote: > > On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: > > > An XFree86 bugzilla is now available at <http://bugs.xfree86.org/>. > > > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for > > > hosting, and the many developers who helped configure and test it. > > > > This is great news. I think a great job was done organizing the products > > and components. > > .... > > I dont get it. Why is this suddenly great news, when DRI could have been > using sourceforge's bugtracking system all this time? Search the dri-devel archives of half-year ago and you'll know why... In summary, we reached no agreement on how bugs should be reported/handled. Some people (including myself) had hope that a bug tracking system based on Bugzilla could gather more acceptance, but it was difficult to setup and we didn't had the human/techical resources to set it up. That's why I cheered this announcement, although I know that in the end it depends solely on the DRI developers - the availability of a Bugzilla bug tracking system doesn't warrant that history doesn't repeat, and everything just remains the same. José Fonseca |
From: Mike A. H. <mh...@re...> - 2003-03-20 02:22:26
|
On Wed, 19 Mar 2003, Philip Brown wrote: >> > An XFree86 bugzilla is now available at <http://bugs.xfree86.org/>. >> > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for >> > hosting, and the many developers who helped configure and test it. >> >> This is great news. I think a great job was done organizing the products >> and components. >> .... > >I dont get it. Why is this suddenly great news, when DRI could have been >using sourceforge's bugtracking system all this time? Because sourceforge's bug tracking system sucks? [1] >However, it seems the decision to abandon that methodology was somehow made >around 2001, judging by all the bug reports already sitting on >http://sourceforge.net/tracker/?group_id=387&atid=100387 Because sourceforge's bug tracking system sucks? [1] >Someone with access should really go through those things, and clear out >all the ones that have now been rendered(ahem) obsolete. Or, someone could just leave it as is, disable it and forget about it because sourceforge's bug tracking system sucks. [1] [1] This is strictly my own personal opinion, and particularly as applies to large projects such as XFree86/DRI/etc. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Keith W. <ke...@tu...> - 2003-03-20 08:14:42
|
> Or, someone could just leave it as is, disable it and forget > about it because sourceforge's bug tracking system sucks. [1] I don't think we ever found out how to disable it. Just another aspect of its suckage - you can't turn it off. Keiht |
From: Philip B. <ph...@bo...> - 2003-03-20 09:28:17
|
On Thu, Mar 20, 2003 at 08:14:33AM +0000, Keith Whitwell wrote: > > > Or, someone could just leave it as is, disable it and forget > > about it because sourceforge's bug tracking system sucks. [1] > > I don't think we ever found out how to disable it. Just another aspect of its > suckage - you can't turn it off. Sounds like the real problem is that none of the DRI sourceforge admins found out how to fully use the bugtracking system there. Yes, there is a way to disable it so that it no longer appears on http://sourceforge.net/projects/dri There's lots of other things you can do with it too, that probably no one on the list has checked into. |
From: Alan C. <al...@lx...> - 2003-03-20 13:49:12
|
On Thu, 2003-03-20 at 09:31, Philip Brown wrote: > On Thu, Mar 20, 2003 at 08:14:33AM +0000, Keith Whitwell wrote: > > > > > Or, someone could just leave it as is, disable it and forget > > > about it because sourceforge's bug tracking system sucks. [1] > > > > I don't think we ever found out how to disable it. Just another aspect of its > > suckage - you can't turn it off. > > Sounds like the real problem is that none of the DRI sourceforge admins > found out how to fully use the bugtracking system there. > > Yes, there is a way to disable it so that it no longer appears on > http://sourceforge.net/projects/dri > There's lots of other things you can do with it too, that probably no one > on the list has checked into. I guess they've been busy writing 3D drivers instead. If you know the SF system well then this kind of info could be a real help |
From: Philip B. <ph...@bo...> - 2003-03-20 20:06:27
|
On Thu, Mar 20, 2003 at 02:49:37PM +0000, Alan Cox wrote: >... > I guess they've been busy writing 3D drivers instead. If you know the > SF system well then this kind of info could be a real help I dont know it "well". I just poked around with it at admin-level for 10 minutes. It would be a good thing if one or more of the current DRI sourceforge area admins took a similar amount of time and invested it in the system. |
From: Mike A. H. <mh...@re...> - 2003-03-20 02:20:01
|
On Wed, 19 Mar 2003, [iso-8859-15] Jos=E9 Fonseca wrote: >I know that the current policy on DRI is to post bugs on dri-users or >dri-devel, but with XFree86 having a bug database is inevitable that >people will eventually post bugs there too. Therefore what's the >possibility of: > - Setting up a general "owner" for DRI bugs, which probably would be > dri...@li.... > - automatically set the owner of DRI bugs, e.g., by the users adding a > "DRI" keyword, or associating the "XFree86 Server"->"DRI" extension > component. > - Add the possibility to add comments to bugs via e-mail. Bugzilla requires a valid authenticated login. Not possible to=20 do that with email->bugzilla at least currently. >Basically I would like to be possible that: > - An user adds a bug concerning DRI > - The owner is (either manually or automatically) set to > dri...@li..., which receives the bug > - Any developer on the dri-devel list which has an account on > XFree86 Bugzilla can reply and that comment is added to the bug > database. Click on the URL in the bugzilla email, the bug comes up, and you=20 can enter a comment directly into bugzilla. Even pine can do=20 this easily. --=20 Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |