On Thu, 9 May 2002, Michael wrote: >> >> High resolution video requires a lot of video memory. DRI >> >> requires approximately four TIMES that much video memory to work >> >> properly. However, people are using insane high resolutions like >> >> 1600x1200 and using DRI, then running Wolfenstein 3D, and it >> >> crashes. Hmm, gee... I wonder why. > >Perhaps because the voodoo3 will happily run at these resolutions? >Doesn't sound insane to me.
Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. I am interested in hearing the opinions of DRI and XFree86 project members on the this particular issue with the tdfx driver. I have a feeling however that the DRI developers favor stability, reliability, and security over driver features, supported resolutions and the like. If someone wants to modify a driver and use it in a known unstable manner, and they're lucky enough to not trigger problem behaviour, or to trigger it infrequently enough that it doesn't bother them, that is their perogative. But it is not acceptable IMHO to knowingly ship a driver which crashes, and for which the reason for the crash can be easily fixed or worked around by detecting problem configurations and disabling features known to be unstable. If someone wants to see this problem fixed in a better way than just being worked around by disabling the known problematic configuration, then it is a good project for someone to work on as a personal itch to scratch, and to ensure that the tdfx drivers continue to function and to access as many features of the hardware as possible. Unmaintained drivers eventually become non-working drivers, and eventually become completely disabled drivers. As hardware becomes older, and nobody is funding development of the code, there is less and less incentive to fix bugs in the code, when there are fixed amount of human resources available, and newer drivers for more modern hardware have their own fare share of bugs needing fixing. It makes the most sense to spend resources first on the modern hardware, and much lower priority on the older hardware. It is in these situations when the open source development community needs to step in and scratch their personal itch by hacking on code and contributing it. Not unlike the Linux kernel's own developmental processes. Fortunately, due to the good work that the DRI guys, and others have done in the past on the tdfx drivers, they are in fairly good shape now. This one problem is the only major problem that pops up now that I can think of on Voodoo 3/Banshee hardware. If someone is interested in solving this for real, let me know, and I will put the Voodoo 3 specs up and provide a URL to them. Also, it would be a good idea to join the #dri-devel meetings on irc.openprojects.net on Mondays at 4pm EST to discuss how one might go about finding/fixing the problem. I'm sure that Daryll Strauss, and others who have worked on this code before, will be glad to help out anyone interested by providing pointers. But until such bugs are truely fixed, stability trumps whiz-bang. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
