Some of you may know this, but I didn't and thus I'll share what I learned.
The rpmfusion nvidia driver needs a special xorg.conf file. It might not operate properly with a file that previously operated properly with say a livna sourced driver.
Specifically, it needs this to be present:
Section "Files" ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" EndSection
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
You can read more about this issue here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=197
I hope this helps someone.
On Fri, 2008-11-28 at 12:29 -0500, Linuxguy123 wrote:
The rpmfusion nvidia driver needs a special xorg.conf file. It might not operate properly with a file that previously operated properly with say a livna sourced driver.
Specifically, it needs this to be present:
Section "Files" ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" EndSection
If you're running 64-bit Fedora, be sure these lines actually say:
Section "Files" ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" EndSection
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
In my experience, the kmod-nvidia package installed and created the appropriate xorg.conf file by default just fine. It could have been that I installed using an earlier version of the RPMs where the correct file was preserved through upgrades though. It's _always_ good to check and know for sure.
You can read more about this issue here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=197
I hope this helps someone.
Thanks for pointing it out! I'm sure it will...
Cheers,
Chris
-- ========================================= "In theory there is no difference between theory and practice. In practice there is."
--Yogi Berra
On Fri, 28 Nov 2008 12:29:35 -0500 Linuxguy123 linuxguy123@gmail.com wrote:
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
I thought that was among the things the livna-config-display script did (or as I guess they now renamed it nvidia-config-display)?
Certainly when I installed the rpmfusion drivers with no xorg.conf at all, they created an xorg.conf that included the extra module path info.
On Fri, 2008-11-28 at 14:51 -0500, Tom Horsley wrote:
On Fri, 28 Nov 2008 12:29:35 -0500 Linuxguy123 linuxguy123@gmail.com wrote:
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
I thought that was among the things the livna-config-display script did (or as I guess they now renamed it nvidia-config-display)?
Certainly when I installed the rpmfusion drivers with no xorg.conf at all, they created an xorg.conf that included the extra module path info.
I used nvidia-settings when I was troubleshooting my situation and it definitely did not include both of those lines.
I'll leave it to someone else to test all the xorg.conf generation tools and report back what each one does.
Linuxguy123 wrote:
Some of you may know this, but I didn't and thus I'll share what I learned.
The rpmfusion nvidia driver needs a special xorg.conf file. It might not operate properly with a file that previously operated properly with say a livna sourced driver.
Specifically, it needs this to be present:
Section "Files" ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" EndSection
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
You can read more about this issue here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=197
I hope this helps someone.
Rpmfusion is also missing the xine package.
On Fri, 2008-11-28 at 17:17 -0500, Jim wrote:
Linuxguy123 wrote:
Right now I am unsure if the xorg or nvidia xorg.conf configuration tools will put both these lines in the xorg.conf file. I doubt they do, actually.
You can read more about this issue here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=197
I hope this helps someone.
Rpmfusion is also missing the xine package.
Come to think of it, the fglrx drivers are also missing. ATI/AMD just released a new version of these on 11-18 as well.
Cheers,
Chris
-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.
--Socrates
On 29.11.2008 00:16, Christopher A. Williams wrote:
Come to think of it, the fglrx drivers are also missing. ATI/AMD just released a new version of these on 11-18 as well.
If you get them to work in a proper way(¹) let the RPM Fusion packagers know via http://bugzilla.rpmfusion.org. But they right now afaics simply don't work on F10.
See also: https://www.redhat.com/archives/fedora-announce-list/2008-November/msg00014....
""" Please note that the graphics drivers from AMD are not yet available in the repositories as it seems they don't work with F10 right now. If you know how to make them work let us know, then we'll try to ship them as an update as soon as possible. """
CU knurd
(¹) -- there are dirty hacks known to make them work (you should not use them if you can't find them on your own). Those require one installs the libdrm from F9 -- but that (obviously) is nothing RPM Fusion can or wants do, as we don't want to mess up peoples systems
On Sat, 2008-11-29 at 13:53 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 00:16, Christopher A. Williams wrote:
Come to think of it, the fglrx drivers are also missing. ATI/AMD just released a new version of these on 11-18 as well.
If you get them to work in a proper way(¹) let the RPM Fusion packagers know via http://bugzilla.rpmfusion.org. But they right now afaics simply don't work on F10.
See also: https://www.redhat.com/archives/fedora-announce-list/2008-November/msg00014....
""" Please note that the graphics drivers from AMD are not yet available in the repositories as it seems they don't work with F10 right now. If you know how to make them work let us know, then we'll try to ship them as an update as soon as possible. """
CU knurd
(¹) -- there are dirty hacks known to make them work (you should not use them if you can't find them on your own). Those require one installs the libdrm from F9 -- but that (obviously) is nothing RPM Fusion can or wants do, as we don't want to mess up peoples systems
Wow... A simple "No, it's not working on F10 yet because, among other things, the only known way to get it to work is to downgrade libdrm - which we think is a _really_ bad idea!" would have done just fine.
I spent a few minutes digging on this. The hacks you mentioned appear to date back to releases of the ATI drivers that are earlier than what is currently available from AMD. The current release is version 8.11, which was posted on November 13, 2008, and claims to support X.org versions 6.7 through 7.4 (if that makes a difference). Link to the page I'm talking about is:
http://ati.amd.com/support/drivers/linux64/linux64-radeon.html
Perhaps it would also help if this issue was actually communicated someplace conspicuous on the RPMFusion site. Not everyone looking at RPMFusion will pick up a small paragraph at the end of a rather long post in fedora-announce.
I'm looking at RPMFusion.org right now, and there's absolutely nothing there about this. But there is something in the FAQ section about why people _should_ install the RPMFusion nVidia and ATI drivers, and that in turn provides a link to the "RPMFusionSwitcher" page, which gives complete instructions on how to (allegedly for ATI) do it.
I think the RPMFusion team would save a lot of people (let alone themselves) a fair amount of pain and anguish if they: 1) Provided status on the site (takes less time than it took for you to write your message
2) Asked for help, including giving a technical explanation of the problem(s) with libdrm in F10 and fglrx - or whatever else is the issue.
Maybe then, enough people would escalate things with AMD that they might actually do something to fix the problem, assuming the issue is with the proprietary driver. If I knew enough about complex packaging of drivers for X, I would gladly help. Unfortunately I'm an Enterprise Infrastructure Architect, and am not "hacker qualified" in the X.org driver development area.
Cheers,
Chris
-- ==================================== "If you get to thinkin' you're a person of some influence, try orderin' someone else's dog around."
--Cowboy Wisdom
On 29.11.2008 17:52, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 13:53 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 00:16, Christopher A. Williams wrote:
Come to think of it, the fglrx drivers are also missing. ATI/AMD just released a new version of these on 11-18 as well.
If you get them to work in a proper way(¹) let the RPM Fusion packagers know via http://bugzilla.rpmfusion.org. But they right now afaics simply don't work on F10.
See also: https://www.redhat.com/archives/fedora-announce-list/2008-November/msg00014....
""" Please note that the graphics drivers from AMD are not yet available in the repositories as it seems they don't work with F10 right now. If you know how to make them work let us know, then we'll try to ship them as an update as soon as possible. """
(¹) -- there are dirty hacks known to make them work (you should not use them if you can't find them on your own). Those require one installs the libdrm from F9 -- but that (obviously) is nothing RPM Fusion can or wants do, as we don't want to mess up peoples systems
Wow... A simple "No, it's not working on F10 yet because, among other things, the only known way to get it to work is to downgrade libdrm - which we think is a _really_ bad idea!" would have done just fine.
It wasn't meant as offense. If it came over as one: sorry.
I spent a few minutes digging on this. The hacks you mentioned appear to date back to releases of the ATI drivers that are earlier than what is currently available from AMD.
Then you to the best of my knowledge digged into the wrong direction. See: http://forums.fedoraforum.org/showthread.php?t=205030&page=2
Perhaps it would also help if this issue was actually communicated someplace conspicuous on the RPMFusion site. Not everyone looking at RPMFusion will pick up a small paragraph at the end of a rather long post in fedora-announce.
I'm looking at RPMFusion.org right now, and there's absolutely nothing there about this. But there is something in the FAQ section about why people _should_ install the RPMFusion nVidia and ATI drivers, and that in turn provides a link to the "RPMFusionSwitcher" page, which gives complete instructions on how to (allegedly for ATI) do it.
I think the RPMFusion team would save a lot of people (let alone themselves) a fair amount of pain and anguish if they:
- Provided status on the site (takes less time than it took for you to
write your message
- Asked for help, including giving a technical explanation of the
problem(s) with libdrm in F10 and fglrx - or whatever else is the issue.
Maybe then, enough people would escalate things with AMD that they might actually do something to fix the problem, assuming the issue is with the proprietary driver. If I knew enough about complex packaging of drivers for X, I would gladly help. Unfortunately I'm an Enterprise Infrastructure Architect, and am not "hacker qualified" in the X.org driver development area.
Fully agreed. But that needs volunteers and people that actually do that. most RPM Fusion contributors are already overloaded. Would you want to help?
Cu knurd
On Sat, 2008-11-29 at 18:11 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 17:52, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 13:53 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 00:16, Christopher A. Williams wrote:
<snip...>
Wow... A simple "No, it's not working on F10 yet because, among other things, the only known way to get it to work is to downgrade libdrm - which we think is a _really_ bad idea!" would have done just fine.
It wasn't meant as offense. If it came over as one: sorry.
No worries - I forgive you... :)
I spent a few minutes digging on this. The hacks you mentioned appear to date back to releases of the ATI drivers that are earlier than what is currently available from AMD.
Then you to the best of my knowledge digged into the wrong direction. See: http://forums.fedoraforum.org/showthread.php?t=205030&page=2
Indeed...!
I followed this thread and found much more current information from many of the same posters. So, if I read this correctly, the only known way to work around what amounts to bad coding practice by ATI/AMD in their proprietary drivers (Sheesh! I can't believe developers still like to hard code directory paths when there's no reason to!!!) would be to use bad packaging practice.
Perhaps it would also help if this issue was actually communicated someplace conspicuous on the RPMFusion site. Not everyone looking at RPMFusion will pick up a small paragraph at the end of a rather long post in fedora-announce.
I'm looking at RPMFusion.org right now, and there's absolutely nothing there about this. But there is something in the FAQ section about why people _should_ install the RPMFusion nVidia and ATI drivers, and that in turn provides a link to the "RPMFusionSwitcher" page, which gives complete instructions on how to (allegedly for ATI) do it.
I think the RPMFusion team would save a lot of people (let alone themselves) a fair amount of pain and anguish if they:
- Provided status on the site (takes less time than it took for you to
write your message
- Asked for help, including giving a technical explanation of the
problem(s) with libdrm in F10 and fglrx - or whatever else is the issue.
Maybe then, enough people would escalate things with AMD that they might actually do something to fix the problem, assuming the issue is with the proprietary driver. If I knew enough about complex packaging of drivers for X, I would gladly help. Unfortunately I'm an Enterprise Infrastructure Architect, and am not "hacker qualified" in the X.org driver development area.
Fully agreed. But that needs volunteers and people that actually do that. most RPM Fusion contributors are already overloaded. Would you want to help?
RPMFusion Wiki Account / Profile and Bugzilla account created successfully. Glad to help where I am able. Let me know...
Cheers,
Chris
-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.
--Socrates
On Sat, 29 Nov 2008 11:08:04 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
(Sheesh! I can't believe developers still like to hard code directory paths when there's no reason to!!!) would be to use bad packaging practice.
Hey, if it will help anyone I have a handy program I've often used for things like this. It can take a binary blob, look for strings, and substitute different strings of equal or lesser length (padded out will nul bytes if it is a shorter string).
Great for building stuff that thinks it should be installed in /some/testing/place/usr/lib/whatever, testing it, then transforming the binaries to think they are at /usr/lib/whatever once you are ready to install for real.
On Sat, 2008-11-29 at 13:57 -0500, Tom Horsley wrote:
On Sat, 29 Nov 2008 11:08:04 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
(Sheesh! I can't believe developers still like to hard code directory paths when there's no reason to!!!) would be to use bad packaging practice.
Hey, if it will help anyone I have a handy program I've often used for things like this. It can take a binary blob, look for strings, and substitute different strings of equal or lesser length (padded out will nul bytes if it is a shorter string).
Great for building stuff that thinks it should be installed in /some/testing/place/usr/lib/whatever, testing it, then transforming the binaries to think they are at /usr/lib/whatever once you are ready to install for real.
Hmm... Could be useful indeed. The only question here is if we can both modify the ATI proprietary code as needed with it AND then legally distribute the modified version via RPMFusion.
We could possibly modify the ATI code, make sure it works, and then send the modified version back to ATI as a patch to get their blessing.
Thoughts?
Cheers,
Chris
-- ========================================= "In theory there is no difference between theory and practice. In practice there is."
--Yogi Berra
On Sat, 29 Nov 2008 12:31:43 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
Hmm... Could be useful indeed. The only question here is if we can both modify the ATI proprietary code as needed with it AND then legally distribute the modified version via RPMFusion.
Or maybe the lawyers would be happier if you shipped the string changing program with the rpm and did the mods during the install :-).
On 29.11.2008 19:08, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 18:11 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 17:52, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 13:53 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 00:16, Christopher A. Williams wrote:
<snip...>
Perhaps it would also help if this issue was actually communicated someplace conspicuous on the RPMFusion site. Not everyone looking at RPMFusion will pick up a small paragraph at the end of a rather long post in fedora-announce.
I'm looking at RPMFusion.org right now, and there's absolutely nothing there about this. But there is something in the FAQ section about why people _should_ install the RPMFusion nVidia and ATI drivers, and that in turn provides a link to the "RPMFusionSwitcher" page, which gives complete instructions on how to (allegedly for ATI) do it. [...]
Fully agreed. But that needs volunteers and people that actually do that. most RPM Fusion contributors are already overloaded. Would you want to help?
RPMFusion Wiki Account / Profile and Bugzilla account created successfully.
Welcome!
Glad to help where I am able. Let me know...
Well, it's a bit like it's often in the Open-Source-World afaics: Simply set yourself a goal and work towards it. Don't be shy and don't fear to much that you might step on somebodies toes as long as your work is an overall improvement.
Maybe you could actually give the wiki some love to fix the points you raised earlier in this discussion? I for one would fine something like this really great for our wiki:
- a page that people can watch/subscribe to to get a up2date status of what happening in regrards to the graphics drivers
- a page that descries the differences between the different nvidia driver series
- maybe merge http://rpmfusion.org/RPMFusionSwitcher and https://www.redhat.com/archives/fedora-test-list/2006-February/msg01565.html and http://fedoraproject.org/wiki/Xorg/3rdPartyVideoDrivers ; explain on it why we use the xorg.conf hack with the ExtensionDir and the ld.conf.d-hack to point to let apps use the libGL.so.1 from nvidia
- explain the dangers of attconfig, nvidia-xconfig and other tools until a real solution is found (see https://bugzilla.rpmfusion.org/show_bug.cgi?id=197 https://bugzilla.rpmfusion.org/show_bug.cgi?id=204 )
- a "how to debug problems with the graphics driver packages from RPM Fusion". E.g. check if kmod is loaded, check dmesg for messages from module, check Xorg.0.log, check if the extension path is set in xorg.conf, glxinfo in general, LIBGL_DEBUG=verbose glxinfo, ldd /usr/bin/glxinfo; games with hardcoded rpath might not work -- things like that
There are likely other things that I forgot right here, but maybe that gives you some ideas/impressions (and if you don't understand some of the things I said simply ignore them or ask for advice). Steward and Nicolas (CCed) can likely help and answer questions if needed as well -- those two take care of the graphic driver packages in RPM Fusion.
Cu knurd
Just a quick update to say that the developer chatter on the bugzilla for this matter is pretty interesting. They are taking this matter to heart.
On Sun, 2008-11-30 at 14:50 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 19:08, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 18:11 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 17:52, Christopher A. Williams wrote:
On Sat, 2008-11-29 at 13:53 +0100, Thorsten Leemhuis wrote:
On 29.11.2008 00:16, Christopher A. Williams wrote:
<snip...>
Perhaps it would also help if this issue was actually communicated someplace conspicuous on the RPMFusion site. Not everyone looking at RPMFusion will pick up a small paragraph at the end of a rather long post in fedora-announce.
I'm looking at RPMFusion.org right now, and there's absolutely nothing there about this. But there is something in the FAQ section about why people _should_ install the RPMFusion nVidia and ATI drivers, and that in turn provides a link to the "RPMFusionSwitcher" page, which gives complete instructions on how to (allegedly for ATI) do it. [...]
Fully agreed. But that needs volunteers and people that actually do that. most RPM Fusion contributors are already overloaded. Would you want to help?
RPMFusion Wiki Account / Profile and Bugzilla account created successfully.
Welcome!
Glad to help where I am able. Let me know...
Well, it's a bit like it's often in the Open-Source-World afaics: Simply set yourself a goal and work towards it. Don't be shy and don't fear to much that you might step on somebodies toes as long as your work is an overall improvement.
Maybe you could actually give the wiki some love to fix the points you raised earlier in this discussion? I for one would fine something like this really great for our wiki:
- a page that people can watch/subscribe to to get a up2date status of
what happening in regrards to the graphics drivers
- a page that descries the differences between the different nvidia
driver series
- maybe merge http://rpmfusion.org/RPMFusionSwitcher and
https://www.redhat.com/archives/fedora-test-list/2006-February/msg01565.html and http://fedoraproject.org/wiki/Xorg/3rdPartyVideoDrivers ; explain on it why we use the xorg.conf hack with the ExtensionDir and the ld.conf.d-hack to point to let apps use the libGL.so.1 from nvidia
- explain the dangers of attconfig, nvidia-xconfig and other tools until
a real solution is found (see https://bugzilla.rpmfusion.org/show_bug.cgi?id=197 https://bugzilla.rpmfusion.org/show_bug.cgi?id=204 )
- a "how to debug problems with the graphics driver packages from RPM
Fusion". E.g. check if kmod is loaded, check dmesg for messages from module, check Xorg.0.log, check if the extension path is set in xorg.conf, glxinfo in general, LIBGL_DEBUG=verbose glxinfo, ldd /usr/bin/glxinfo; games with hardcoded rpath might not work -- things like that
There are likely other things that I forgot right here, but maybe that gives you some ideas/impressions (and if you don't understand some of the things I said simply ignore them or ask for advice). Steward and Nicolas (CCed) can likely help and answer questions if needed as well -- those two take care of the graphic driver packages in RPM Fusion.
OK - Sounds like a good starting plan. I'm on the road this week kicking off a new client engagement. That has me pretty swamped at the moment, but I will start looking at this more in-depth as I get some spare cycles this week.
Cheers,
Chris
On Sat, 29 Nov 2008 09:52:28 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
Wow... A simple "No, it's not working on F10 yet because, among other things, the only known way to get it to work is to downgrade libdrm - which we think is a _really_ bad idea!" would have done just fine.
Are you sure that you still need the proprietary ATI driver? I couldn't get the open-source driver to work with my widescreen monitor (Acer AL2223W) on F9 and below so I very reluctantly installed the proprietary driver.
But with F10 the open-source raedon driver works great with my X1550 card and my display looks beautiful (or at least, not much different than it did with the proprietary driver. )
[frankcox@mutt ~]$ glxgears 7606 frames in 5.0 seconds = 1521.163 FPS 7600 frames in 5.0 seconds = 1519.919 FPS 7600 frames in 5.0 seconds = 1519.894 FPS 7575 frames in 5.0 seconds = 1514.896 FPS
Suits me fine. And no more horsing around with any proprietary driver.
On Sun, 2008-11-30 at 00:05 -0600, Frank Cox wrote:
On Sat, 29 Nov 2008 09:52:28 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
Wow... A simple "No, it's not working on F10 yet because, among other things, the only known way to get it to work is to downgrade libdrm - which we think is a _really_ bad idea!" would have done just fine.
Are you sure that you still need the proprietary ATI driver? I couldn't get the open-source driver to work with my widescreen monitor (Acer AL2223W) on F9 and below so I very reluctantly installed the proprietary driver.
But with F10 the open-source raedon driver works great with my X1550 card and my display looks beautiful (or at least, not much different than it did with the proprietary driver. )
[frankcox@mutt ~]$ glxgears 7606 frames in 5.0 seconds = 1521.163 FPS 7600 frames in 5.0 seconds = 1519.919 FPS 7600 frames in 5.0 seconds = 1519.894 FPS 7575 frames in 5.0 seconds = 1514.896 FPS
Suits me fine. And no more horsing around with any proprietary driver.
No such luck here. This is running on my laptop, which has switchable graphics. You change this in CMOS. Here goes...
Laptop: Lenovo ThinkPad T400 (Model 2765-T6U) Internal Graphics: Intel Cantiga Graphics Controller Discreete Graphics: ATI Mobility Radeon HD3470
On Intel "Integrated" Graphics (Open Source Intel Driver): [chris@SpikePad Desktop]$ glxgears 6314 frames in 5.0 seconds = 1262.720 FPS 3286 frames in 5.0 seconds = 656.852 FPS 2185 frames in 5.0 seconds = 436.959 FPS 6359 frames in 5.0 seconds = 1271.672 FPS 6424 frames in 5.0 seconds = 1284.792 FPS 6448 frames in 5.0 seconds = 1289.470 FPS
On ATI "Discreete" Graphics (Open Source Radeon Driver): [chris@SpikePad Desktop]$ glxgears 1965 frames in 5.0 seconds = 392.970 FPS 1973 frames in 5.0 seconds = 394.572 FPS 1974 frames in 5.0 seconds = 394.695 FPS 1973 frames in 5.0 seconds = 394.441 FPS 1972 frames in 5.0 seconds = 394.300 FPS 1973 frames in 5.0 seconds = 394.402 FPS
On ATI "Discreete" Graphics (Open Source RadeonHD Driver): [chris@SpikePad Desktop]$ glxgears 1913 frames in 5.0 seconds = 382.543 FPS 1910 frames in 5.0 seconds = 381.886 FPS 1911 frames in 5.0 seconds = 382.150 FPS 1909 frames in 5.0 seconds = 381.639 FPS 1910 frames in 5.0 seconds = 381.951 FPS 1908 frames in 5.0 seconds = 381.418 FPS
Not to mention that Compiz doesn't work at all with either ATI driver.
...So, yeah, I think I need the proprietary ATI driver if I'm going to get any performance out of my laptop's ATI graphics controller. It's supposed to be faster (according to Lenovo) than the Intel controller as well.
Kind of ironic that the "slower" Intel controller works better, with a default "out of the box" setup than the ATI controller, ain't it. :)
Cheers,
Chris
-- =================================== Warning: You are logged into reality as the root user...
--Unknown
On Sun, 30 Nov 2008 14:17:12 -0700 "Christopher A. Williams" chriswfedora@cawllc.com wrote:
Kind of ironic that the "slower" Intel controller works better, with a default "out of the box" setup than the ATI controller, ain't it. :)
Nah, that's not ironic, that's just Intel always having had support for an open driver.
I keep hearing rumors that Intel might make a PCI-E video card someday. I wish they would, I'd switch to one just to support their open source driver.
On Sun, 30 Nov 2008 16:37:43 -0500 Tom Horsley tom.horsley@att.net wrote:
I keep hearing rumors that Intel might make a PCI-E video card someday. I wish they would, I'd switch to one just to support their open source driver.
For the past several years I've always made sure that any computer that I purchase has an Intel video chipset, simply because it's the best-supported chipset for Linux. However, with the last computer that I bought (this one) the built-in video has a very slight crawl on my widescreen monitor. Slight enough that you don't notice it when you first sit down in front of the computer, but significant enough that it drives me nuts after ten minutes.
So I was more-or-less forced to buy a separate video card for this computer. The guys at the computer store I make most of my purchases from asked if I wanted a Nvidia or ATI. I said that I want an ATI due to their new open source policy so that's what I got. Either the separate card on its own or the DVI output that I'm now using cured the crawl. I suspect it's some kind of electrical interference that was causing it.
I never really wanted to use the proprietary ATI driver, but was again kind of forced into it when the open source driver didn't work with my widescreen monitor. I was hoping that would change some day and now it has.
Now that I can use the "comes-with-Fedora 10" Raedon driver, I'm happy as a clam.
On 28.11.2008 23:17, Jim wrote:
[...] Rpmfusion is also missing the xine package.
You seems to be quite sure with that. But what's this then: http://download1.rpmfusion.org/free/fedora/releases/10/Everything/i386/os/re... http://download1.rpmfusion.org/free/fedora/releases/10/Everything/x86_64/os/...
CU knurd
On 28.11.2008 18:29, Linuxguy123 wrote:
Some of you may know this, but I didn't and thus I'll share what I learned.
The rpmfusion nvidia driver needs a special xorg.conf file. It might not operate properly with a file that previously operated properly with say a livna sourced driver.
Specifically, it needs this to be present:
Section "Files" ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" EndSection
Note: Something like that is required by the livna packages (which are now in RPM Fusion) for years now. The enable/disable scripts add that part to the config files automatically if everything works fine.
IOW: if you just type "yum install kmod-nvidia" it'll just work. If you overwrite the config with nvidia-xconfig afterwards then it won't work. I hope the current driver maintainer fix that soon. Details:
Further: Maintaining the drivers is a whole lot of work. RPM Fusion afaics could need some people that help with it -- RPM packaging skills would help, but testing packages, helping to fix bugs and writing documentation is afaics needed as well. Any volunteers?
CU knurd
Linuxguy123 wrote:
Some of you may know this, but I didn't and thus I'll share what I learned.
The rpmfusion nvidia driver needs a special xorg.conf file. It might not operate properly with a file that previously operated properly with say a livna sourced driver.
I posted this last week but did not get any replies. Related?
"Now that F8 is nearing its EOL, I decided to upgrade my F8 system to F9.
I launched preupgrade, selected F9, and completed the download. When I rebooted, anaconda launched but when X started, after it correctly detected my graphics card, a nVidia 8800, it chose the wrong settings either for the card or the monitor resulting in a blank screen.
I was able to <ctrl><alt> <F1> to see some anaconda messages and after I rebooted again, I was able to boot back into into F8 with no problem.
Is there something I can add to the boot line to tell anaconda to use my existing Xorg.conf file?"
Thanks, Steve
-
Christopher A Williams -
Frank Cox -
Jim -
linux guy -
Steve Blackwell -
Thorsten Leemhuis -
Tom Horsley