On Fri, 3 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: >> drivers simply do not require that option at all for any good >> reason other than for developer usage. Any other usage of the >> option would be very non-general. The Radeon driver is such an >> example, as it perfectly detects video memory for all Radeon >> hardware on all architectures. > >The radeon driver doesn't really support your point though, from >radeon_driver.c:
No... It doesn't support your personal interpretation of my point. It does however support my real point. > /* Some production boards of m6 will return 0 if it's 8 MB */ > if (pScrn->videoRam == 0) pScrn->videoRam = 8192; > >Such problems can always occur, which is precisely what the VideoRam >directive is for. The only problem I see is config tools presenting it >as something it isn't. Sure they can occur. And if a problem occurs where the Radeon driver does not detect memory on a given board, either due to a driver bug, BIOS bug, hardware bug, then it is a bug period, and that can be addressed by a video driver update. Regardless of what XFree86.org is willing to accept into the Radeon driver, *I* am willing to accept that into my version of the driver, as it solves real world problems for me and our customers and users. The number of users it might cause problems for, currently is estimated at zero. Should someone report a bug, then that will be estimated at slightly-more-than-zero, and that bug can be fixed, either via information provided by ATI's documenation and/or engineers, or by modifyingy my patch to not disable the option on that one chip that has a problem. The code fragment above indicates that a specific chip required special handling, either due to a hardware difference, or possibly due to a bug, and my interpretation of the code, is that the memory is properly detected by that code workaround. If I remember correctly, I reported that actual problem to Hui Yu about 1-2 years ago, and he fixed it with that workaround. Other drivers have had VideoRAM option disabled for them already and that seems to not cause problems for users of those drivers, or people would file bug reports about it. At any rate, as I stated multiple times now, I am solving a problem for myself, and our X users. If that solution is useful to a wider audience, they're welcome to it of course, and I'll do what I can to make it useful to others. >> If for any reason someone can point out a case where it doesn't, I'm >> almost certain that myself, Michel Daenzer, someone from ATI, or >> another Radeon developer could fix the problem easily enough. > >The delay imposed by deploying such a fix seems far from ideal though. I see no evidence of this being a problem in real world usage in any of the video drivers that already do this. If a user does report a problem to me, I can have them an updated test driver within about 15 minutes from receiving the bug report, partially due to the amount of time resources I save not having to chase down bogus bug reports caused by people who have that option gratuitously set. The "ideal" fix, is to have the drivers non-broken to begin with, and autodetect everythign properly. XFree86 has a goal of making things easier to work for people out of the box without requiring configuration, and that is evidenced by David's latest development efforts posted recently. I'm sure anything that hampers autodetection will be important where possible to fix. Again however - my solution, which _will_ solve my problems, is not in any way forced upon you personally, nor anyone else. Not unless you use my XFree86 builds anyway. And if a legitimate problem can be pointed out to me which I consider relevant and not just pedantic bickering and hypothetical situations, I'm very open minded about fixing problems in ways that benefit people, as long as it doesn't cause more work for me overall due to support problems and bug reports received. -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
