Red Hat Bugzilla – Bug 68269
add support for utah-glx open GL drivers
Last modified: 2007-04-18 12:43:58 EDT
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):
Steps to Reproduce:
Actual Results: N/A
Expected Results: Happy users with tested, open source hardware acceleration on
nVidia graphics cards. ;)
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.