FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If you want good linux performance now, pick up a FX 5950 from Nvidia.
The ATI drivers are just not up to scratch at the moment. Take back the card for a refund, and buy nvidia instead.
I love my ATI cards, they are the best for Windows gaming, but under linux the drivers are poor, and I doubt they will improve for a good 6 months to a year
Forgive me for slipping into the thread, but it seems like the people I need advice from are right here...and I'm just not comfortable with kernel modules.
If I'm running ATI 3.7.6 drivers in SuSE 9.1 (SuSE rpms) and want to upgrade to the SuSE packaged 3.9 drivers, would I follow the same procedure as a new install? Or do I need to do something to remove or disable the old drivers first?
Thanks,
Keith
<just noticed this is the Fedora board...I must have been asleep when I wrote it...sorry.>
Originally posted by proudclod If you want good linux performance now, pick up a FX 5950 from Nvidia.
The ATI drivers are just not up to scratch at the moment. Take back the card for a refund, and buy nvidia instead.
I love my ATI cards, they are the best for Windows gaming, but under linux the drivers are poor, and I doubt they will improve for a good 6 months to a year
So I will get the same performance running a 5950 on Linux as I would in Windows? Give or take or is the stilla big difference, just not as poor as ATI?
I'm in the same boat! I installed the ATI drivers by the book, and prolly did it a dozen times too. I'm still getting this Mesa GLX Indirect bull****. I have a 9600XT and RedHat EL 3 (2.4.21). Please, please, please, someone tell me how to make this work!
Quote:
Originally posted by carlwill Guys - I thought my ATI drivers are working but they are not.
ok, I am past the frustration since I have come so far even though I have nothing to show for it except a sucessful install of FC1.
When I type in "flrxinfo" in konsole, it reads this...
Did you ever actually load the drivers with modprobe fglrx? I've found this to happen when I configured fglrx without loading the drivers first, and of course it will occur if I haven't restarted the X server using either CTRL+ALT+Backspace, or by rebooting, as the "other" drivers I previously used are still loaded in memory until I do.
And naturally, if DRI is not disabled in the kernel (as it should be), you will get this as well, since the kernel drivers will take precedence over the inserted fglrx drivers.
Lastly, did you edit the correct file with the fglrxconfig utility? The default save name for the file generated by fglrxconfig is /etc/X11/XF86Config-4, but that doesn't do you much good if the default X configuration file for your distro is /etc/X11/XF86Config, /etc/XF86Config, or --in the event that you use X.org and not XFree86-- /etc/X11/xorg.conf.
So it's possible that your distribution is not even using the file you just generated, in which case you should run fglrxconfig again and save to the correct filename, or just copy the generated file over the correct file (back up the old one first).
I don't know how to check whether or not DRI is loaded into the kernel by default. I'm using RedHat Enterprise Linux 3 AS, which has it's own custom 2.4.21 kernel.
The fact that it's used by 0 services is not really relevant, since we already know you aren't using the fglrx driver to drive the X server in your current session.
But the fact that it loads OK is a good sign.
What we would like to do now is to actually have the driver being the one used to drive the X server in future sessions.
So it seems to me we need to know what config file X is actually using, whether that is the same one you have configured, and what driver you're using atm. I suspect the "radeon" driver from the kernel, since drivers loaded by the kernel tend not to appear in an lsmod, that driver would use the kernel DRM, and obviously, nothing in your list is using any video devices-- but you have X in some way atm, so something is using the device. Just not anything on the lsmod list.
Which X server are you using, XFree86 or X.org? If the latter, I would check /etc/ and /etc/X11/, find the file I configured using fglrxconfig, and just copy it to /etc/X11/xorg.conf (not forgetting to change the font paths). if XFree86, I would check the same two folders and see just how many XFree86 configuration files I actually had, then try to figure out which one was supposed to be the one in use, then copy the file that I configured using fglrxconfig to that file (backing up the other first).
I'm sure there's a way to get X to tell you what config file it's using, but I don't know it offhand, and I don't have time to look it up atm.
# File: XF86Config-4
# File generated by fglrxconfig (C) ATI Research, a substitute for xf86config.
# Note by ATI: the below copyright notice is there for servicing possibly
# pending third party rights on the file format and the instance of this file.
#
# Copyright (c) 1999 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# **********************************************************************
# Refer to the XF86Config(4/5) man page for details about the format of
# this file.
# **********************************************************************
# **********************************************************************
# DRI Section
# **********************************************************************
Section "dri"
# Access to OpenGL ICD is allowed for all users:
Mode 0666
# Access to OpenGL ICD is restricted to a specific user group:
# Group 100 # users
# Mode 0660
EndSection
# **********************************************************************
# Module section -- this section is used to specify
# which dynamically loadable modules to load.
# **********************************************************************
#
Section "Module"
# This loads the DBE extension module.
Load "dbe" # Double buffer extension
# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
SubSection "extmod"
# Option "omit xfree86-dga"
EndSubSection
# This loads the Type1 and FreeType font modules
Load "type1"
Load "freetype"
# This loads the GLX module
Load "glx" # libglx.a
Load "dri" # libdri.a
EndSection
# **********************************************************************
# Files section. This allows default font and rgb paths to be set
# **********************************************************************
Section "Files"
# The location of the RGB database. Note, this is the name of the
# file minus the extension (like ".txt" or ".db"). There is normally
# no need to change the default.
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (which are concatenated together),
# as well as specifying multiple comma-separated entries in one FontPath
# command (or a combination of both methods)
#
# If you don't have a floating point coprocessor and emacs, Mosaic or other
# programs take long to start up, try moving the Type1 and Speedo directory
# to the end of this list (or comment them out).
#
# The module search path. The default path is shown here.
# ModulePath "/usr/X11R6/lib/modules"
EndSection
# **********************************************************************
# Server flags section.
# **********************************************************************
Section "ServerFlags"
# Uncomment this to cause a core dump at the spot where a signal is
# received. This may leave the console in an unusable state, but may
# provide a better stack trace in the core dump to aid in debugging
# Option "NoTrapSignals"
# Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
# This allows clients to receive this key event.
# Option "DontZap"
# Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
# sequences. This allows clients to receive these key events.
# Option "Dont Zoom"
# Uncomment this to disable tuning with the xvidtune client. With
# it the client can still run and fetch card and monitor attributes,
# but it will not be allowed to change them. If it tries it will
# receive a protocol error.
# Option "DisableVidModeExtension"
# Uncomment this to enable the use of a non-local xvidtune client.
# Option "AllowNonLocalXvidtune"
# Uncomment this to disable dynamically modifying the input device
# (mouse and keyboard) settings.
# Option "DisableModInDev"
# Uncomment this to enable the use of a non-local client to
# change the keyboard or mouse settings (currently only xset).
Identifier "Keyboard1"
Driver "Keyboard"
# For most OSs the protocol can be omitted (it defaults to "Standard").
# When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
# uncomment the following line.
# Option "Protocol" "Xqueue"
Option "AutoRepeat" "500 30"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option "XkbLayout" "de"
# or:
# Option "XkbLayout" "de"
# Option "XkbVariant" "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
# Option "XkbOptions" "ctrl:swapcaps"
# These are the default XKB settings for XFree86
# Option "XkbRules" "xfree86"
# Option "XkbModel" "pc101"
# Option "XkbLayout" "us"
# Option "XkbVariant" ""
# Option "XkbOptions" ""
# The chipset line is optional in most cases. It can be used to override
# the driver's chipset detection, and should not normally be specified.
# Chipset "generic"
# The Driver line must be present. When using run-time loadable driver
# modules, this line instructs the server to load the specified driver
# module. Even when not using loadable driver modules, this line
# indicates which driver should interpret the information in this section.
Driver "vga"
# The BusID line is used to specify which of possibly multiple devices
# this section is intended for. When this line isn't present, a device
# section can only match up with the primary video device. For PCI
# devices a line like the following could be used. This line should not
# normally be included unless there is more than one video device
# installed.
# Any number of screen sections may be present. Each describes
# the configuration of a single screen. A single specific screen section
# may be specified from the X server command line with the "-screen"
# option.
Section "Screen"
Identifier "Screen0"
Device "ATI Graphics Adapter"
Monitor "Monitor0"
DefaultDepth 24
#Option "backingstore"
Subsection "Display"
Depth 24
Modes "1280x1024" "1024x768" "800x600"
ViewPort 0 0 # initial origin if mode is smaller than desktop
# Virtual 1280 1024
EndSubsection
EndSection
# Any number of ServerLayout sections may be present. Each describes
# the way multiple screens are organised. A specific ServerLayout
# section may be specified from the X server command line with the
# "-layout" option. In the absence of this, the first section is used.
# When now ServerLayout section is present, the first Screen section
# is used alone.
Section "ServerLayout"
# The Identifier line must be present
Identifier "Server Layout"
# Each Screen line specifies a Screen section name, and optionally
# the relative position of other screens. The four names after
# primary screen name are the screens to the top, bottom, left and right
# of the primary screen.
Screen "Screen0"
# Each InputDevice line specifies an InputDevice section name and
# optionally some options to specify the way the device is to be
# used. Those options include "CorePointer", "CoreKeyboard" and
# "SendCoreEvents".
OK, that all looks fine (assuming that your mouse actually is at /dev/mouse, and that the horizontal and vertical refresh rates for your monitor are correct). The only thing that might be a problem depending on what you want is that you're going to be using Video Overlay rather than OpenGL Overlay, but even that has nothing to do with the drivers actually running.
Have you restarted the X server since you installed the drivers (reboot preferred)?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.