Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611 Description of problem: Would like to request support for utah-glx hardware accelerated Open GL drivers in Red Hat Linux to provide better 3D performance for nVidia graphics cards. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: N/A Actual Results: N/A Expected Results: Happy users with tested, open source hardware acceleration on nVidia graphics cards. ;) Additional info: Support for utah-glx drivers will diminish the need for some users to rely on third party, binary kernel modules for 3D hardware accelerationand could decrease the amount of erroneous kernel bug reports.
I've discussed the possibility of doing just this with Alan Cox at OLS. As things stand right now, the Utah-GLX is not secure. Also, merging it into the distribution would create additional maintenance overhead that isn't worth it currently. Nonetheless, this is something that I would like to see happen at some point, once it can be done in a secure and efficient manner, or possibly ported to the DRI infrastructure. I'm defering this for now, so that it can be re-examined in the future to see if the current issues barring its inclusion have been resolved.
To the best of my knowledge utah-glx is still an insecure project. I've no plans on including it in Red Hat Linux in the future. Hopefully someone who cares enough will either port the drivers to the DRI interfaces, or will come up with some secure alternative method. It's just too much effort for too little gain.
As I keep telling you utah-glx is server side and you are talking out of your arse about security 8)
I've been told by many people, yourself included that Utah-GLX was insecure, and that it had various other problems as well. If this is out my arse, then I've been lied to by people, or misunderstood them. At any rate, I am not including Utah-GLX in Red Hat Linux nor have plans to in the future either. It is too much work to maintain this type of infrastructure at this point in time, secure or not. And we do not have the developer resources to handle problems that would be reported in this additional bundle of code for hardware that is pretty much ancient. It makes no business sense to include this in the distribution, and would be just a liability.