Igor Jagec wrote:
Mike A. Harris wrote:
Both ATI and Nvidia, and perhaps even other 3rd party drivers out there
come in some form of tarball or equivalent form from the particular
vendor. Most users seem to favour the hardware vendor supplied drivers
directly, rather than using more sanely packaged 3rd party packages that
contain the same drivers. This is very unfortunate, because installing
these 3rd party tarball driver installations is very harmful to your
clean OS installation.
Both ATI and Nvidia's proprietary video driver installation utilities
replace the Red Hat supplied libGL library with their own libGL.
Nvidia's driver installs a replacement libglx.a X server module,
removing the Red Hat supplied X.Org module in the process. ATI's
driver may or may not replace libglx.a with it's own, I haven't checked
(but if someone could confirm that, I'd appreciate knowing for certain).
What if we uninstall the official nVidia tarball and install Livna
nvidia package, do we back things in order? Or it takes some extra
manual work? Speaking about libglx.a and stuff. I mean, there it would
be insane if we had to reinstall the whole system because of that. Thanks.
Using the livna ati/nvidia rpms is probably the cleanest method
currently of installing and using the proprietary drivers. Having
said that, you can still have various problems still.
Here are some off the top of my head:
1) Using the proprietary driver, then switching to the OSS driver by
editing xorg.conf and changing from "nvidia" to "nv". This will switch
2D drivers, but unless you comment out the config file changes to
ModulePath, Nvidia's proprietary modules such as libglx.a will still get
loaded, and will complain in the X server log file. Not sure if this
actually causes any real problems or not, but as soon as I see it in a
log file, the bug report becomes blacklisted.
2) Using the proprietary driver (any vendor) and switching to an OSS
driver, without doing a complete full reboot of the system, and ensuring
their kernel modules do not ever load, will mean the OSS driver is using
the hardware in whichever state the proprietary driver happened to leave
it in. This can cause problems if the hardware is not in the state
the OSS driver assumes it to be in. Likewise, once a proprietary kernel
module has been loaded, it _owns_ the kernel. Even if you remove it
with rmmod, it has been in the kernel's memory space and could have done
absolutely anything while it was there. The proprietary kernel modules
for video drivers do _insane_ crazy stuff in the name of performance,
which really screws with the kernel's innards.
For that reason, if you're using the livna rpms, and switching from
proprietary to OSS modules, the best thing to do probably is:
1) Disable any kernel modules from loading if they load at init time by
initscripts or similar, or from modprobe.conf.
2) Make a backup copy of xorg.conf in case you want to use it again
later, or reference it for anything.
3) Run "system-config-display --reconfig" which will generate a
completely fresh config file. DO NOT EDIT THIS FILE. Test it first,
and if there are custom tweaks you wish to make, make them _ONLY_
after you have tested the stock xorg.conf that system-config-display
generates.
4) Reboot the computer or power it right off and back on. This is
critically important to ensure the hardware is reset to factory power
on defaults. A lot of people refuse to reboot, or are strongly against
the idea of doing so, with the idea that Linux never needs to be
rebooted. While Linux generally doesn't need to be rebooted, there are
sometimes some very good benefits to doing so, and this is one of those
cases. Don't fight this step in a childish quest to have higher
uptime or some other useless trivial reason, as you'll may end up
pulling your hair out trying to troubleshoot problems that rebooting
would cure instantly. Focus on solving the real problem, and just
hit the switch.
Hope this helps.
TTYL
P.S. As always, feel free to add this info to the wiki, or paraphrase
and polish, yada yada if desired.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
