Re: General Procedure to get ATI/DRI card running?

[Bruce Labitt]

Believe me, I'm almost there.  I will give the AMD/ATI binary driver a 
try next.  I would really not want to rebuild my applications all over 
again. 

If that fails, well, THEN I'll give the card to someone and buy an 
nvidia.  It would be kind of fun to dabble in gentoo.  In my copious 
spare time. :)

-Bruce

Ben Scott wrote:
> On Wed, Jul 9, 2008 at 4:58 PM, Labitt, Bruce
> <[EMAIL PROTECTED]> wrote:
>   
>> Any other solutions available?  Second opinion?  Anyone?
>> 
>
>   Return the AMD card, buy an NVidia card, and use the proprietary,
> binary-only drivers NVidia provides.  They work with CentOS 5.x.
>
>   I'm sure some people won't like this answer, but I call 'em as I see
> 'em.  NVidia's stuff works, even on the "ancient" (i.e., 18-month-old)
> software so many of us are still using.
>
> -- Ben
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>   

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Ben Scott]

On Wed, Jul 9, 2008 at 4:58 PM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:
> Any other solutions available?  Second opinion?  Anyone?

  Return the AMD card, buy an NVidia card, and use the proprietary,
binary-only drivers NVidia provides.  They work with CentOS 5.x.

  I'm sure some people won't like this answer, but I call 'em as I see
'em.  NVidia's stuff works, even on the "ancient" (i.e., 18-month-old)
software so many of us are still using.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[John Abreau]

My approach is to maintain two types of systems. For applications that
I want to keep 'stable", I put them on a headless server that uses
robust hardware. For my X display, I use a couple client machines
that I wipe and reinstall twice a year with the latest Fedora release.

Basically, I reinstalled client A with Fedora 6 when it was released,
then reinstalled client B with Fedora 7 when that was released,
then client A with Fedora 8, then client B with Fedora 9, etc. If I
want newer hardware, I'll buy a new machine, to replace the aging client
that's scheduled to be upgraded, a few days before the Fedora release.



On Wed, July 9, 2008 5:16 pm, Coleman Kane said:
> On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote:
>> Umm, thanks for your frank assessment.
>>
>> So which is the lesser of evils - using the AMD/ATI proprietary drivers
>> for 3D, or totally rebuilding my system from the ground up?  I presume
>> that I will still have to mess around to get things going.  I've fooled
>> around with this a few days now, I don't like wasting my time - I have
>> plenty to do.
>
> Have you tried their proprietary drivers on your current system yet? Do
> they work on such an old server?
>
> You could always move to a Linux distro that has much newer components
> to it, and start from there. The reason I posted "slackware" was just
> that I've already done that route and felt it would actually be faster
> to do than to shoehorn the development-class X server components into
> your current system. It will be much cleaner.
>
> If you were to just go and download all the development code for the
> X.org modules and start building them, you would start to run into
> compiler problems where some of the X.org headers that you have in
> your /usr/include/* need to actually be removed so that they don't
> override package-local versions of those headers. I don't have a
> verified list of which ones they were but there are a bunch of them. So,
> by trial and error you would waste immense time trying to get these
> packages built for your system.
>
> Starting from a fresh, empty base, you are more likely to have a full
> working product much quicker.
>
>>
>> If I were to do this from the ground up, which distro to choose?  Why
>> slackware?  Why not Gentoo?  I suppose I can have a daily overnight
>> update and recompile everything for the morning.
>>
>> I had originally wanted a relatively stable system.  It appears I can't
>> get any work done with a stable system :(
>>
>
> If you want to keep a stable system, you won't be able to easily do that
> with cutting-edge hardware AND get all the cutting-edge features. This
> is even beginning to be the case with Windows nowadays too (and they
> have no excuse).
>
> From my experience, your options are:
>   - Cutting edge system
>   - Stable system
>
> Choose one. :-)
>
> In my case, I chose the first and use FreeBSD. The "cutting edge" is
> "stable enough" for me, but I would never deploy a system like this onto
> a bunch of office workstations. I would probably use hardware that is at
> least a whole year old, and install FreeBSD 6.2 on them, after verifying
> that all of the hardware has an existing track record of working well
> under FreeBSD (either by buying a test system first, or researching it
> online from someone else who's already bought the hardware).
>
>> Any other solutions available?  Second opinion?  Anyone?
>>
>> Bruce
>
> Maybe it would be worth your time to investigate using the most recent
> development snapshot of the xf86-video-ati driver, from its git repo? It
> *might* be more compatible with older X servers, as it is at least that
> old. The build/install procedure is pretty similar to what you've
> already done with the radeonhd driver from what I can tell. You'll just
> want to change the "radeonhd" into "radeon" in your conf file after you
> build and install the driver.
>
>>
>> -Original Message-
>> From: Coleman Kane [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, July 09, 2008 4:37 PM
>> To: Labitt, Bruce
>> Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org
>> Subject: RE: General Procedure to get ATI/DRI card running?
>>
>> On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote:
>> > Arc led me to believe that I did not have to do that yet.  He said
>> that
>> > the drm did not support radeonhd yet.
>> >
>> > Believe me, this is more complicated than I had anticipated... :)
>> >
>> > Here is the logfile
>> >
>>
>> Firs

RE: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Wed, 2008-07-09 at 17:16 -0400, Coleman Kane wrote:
> On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote:
> > Umm, thanks for your frank assessment. 
> > 
> > So which is the lesser of evils - using the AMD/ATI proprietary drivers
> > for 3D, or totally rebuilding my system from the ground up?  I presume
> > that I will still have to mess around to get things going.  I've fooled
> > around with this a few days now, I don't like wasting my time - I have
> > plenty to do.  
> 
> Have you tried their proprietary drivers on your current system yet? Do
> they work on such an old server?

Uhm, pretty sure nVidia and ATI tend to write their binary drivers with
support for the latest Red Hat Enterprise Linux release in mind *before*
they worry about it working with the latest upstream kernel. Remember,
the ATI proprietary driver is called 'fglrx', as in "FireGL X driver",
and FireGL is their high-end workstation line.



-- 
Jarod Wilson
[EMAIL PROTECTED]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-09 at 17:29 -0400, Labitt, Bruce wrote:
> Hmm, not sure I’m scared of Gentoo – I don’t know enough to be
> scared!  I’ve used SuSE in the past, it is ok.
> 
>  
> 
> How hard is it to set up Gentoo?
> 
>  
Visit:
  * http://www.gentoo.org/doc/en/handbook/index.xml

Pick your architecture from the first row of the first table, with the
description labeled "Latest version, one page per chapter, perfect for
online viewing".

Go read Chapter 1. If it makes sense to you then that is how easy it
will be.

> 
>
> __
> From: Arc Riley [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 09, 2008 5:27 PM
> To: Labitt, Bruce
> Cc: Coleman Kane; gnhlug-discuss@mail.gnhlug.org
> Subject: Re: General Procedure to get ATI/DRI card running?
> 
> 
>  
> 
> Everyone I work with who uses the radeonhd drivers uses Gentoo.
> 
> I agree with Coleman's assessment - it was said earlier in this thread
> that you'd likely need to upgrade your X server, it really is ancient,
> and likely Mesa too.
> 
> The output shows that the radeonhd driver does support your card and
> is detecting it, but something else is going wrong down the chain.
> Since newer Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some
> apps may not even work unless you're running a semi-recent version of
> it.
> 
> If Gentoo scares you, the newest OpenSUSE may be your best bet.
> 
> 
-- 
Coleman Kane


signature.asc
Description: This is a digitally signed message part
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

These days it's not hard at all.  It has a nice installer.

Because Portage is more active than other package systems, people generally
hit more blockers/etc and need to resolve conflicts.  There's a fairly
complete set of instructions on this through the Gentoo Docs project (a
wiki), but it takes more grey matter than other distros as you continue to
use it, and is why many people are afraid of it.  I don't recommend it to
people who don't know or are afraid of editing config files.

Unlike other distros, we don't really have "versions".  My system here was
installed 3-4 years ago, and I've got the same set of packages and support
as anyone installing fresh.  The releases, such as 2008.0, are just
up-to-date install releases so you can start out with a mostly updated
system.

Updating the whole system is as easy as "emerge -auv world", which shows you
(v) what it'll upgrade (u) and ask you (a) for confirmation before doing
anything else.

Unlike other distros you also have MUCH more control over how things are
compiled.  You can select to turn on features you need, disable things you
don't want, etc via USE flags.  For some math/sci apps that can be pretty
important, where other distros just try to compile for most users.

On Wed, Jul 9, 2008 at 5:29 PM, Labitt, Bruce <[EMAIL PROTECTED]>
wrote:

>  Hmm, not sure I'm scared of Gentoo – I don't know enough to be scared!
>  I've used SuSE in the past, it is ok.
>
>
>
> How hard is it to set up Gentoo?
>
>
>  --
>
> *From:* Arc Riley [mailto:[EMAIL PROTECTED]
> *Sent:* Wednesday, July 09, 2008 5:27 PM
> *To:* Labitt, Bruce
> *Cc:* Coleman Kane; gnhlug-discuss@mail.gnhlug.org
> *Subject:* Re: General Procedure to get ATI/DRI card running?
>
>
>
> Everyone I work with who uses the radeonhd drivers uses Gentoo.
>
> I agree with Coleman's assessment - it was said earlier in this thread that
> you'd likely need to upgrade your X server, it really is ancient, and likely
> Mesa too.
>
> The output shows that the radeonhd driver does support your card and is
> detecting it, but something else is going wrong down the chain.  Since newer
> Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may not even
> work unless you're running a semi-recent version of it.
>
> If Gentoo scares you, the newest OpenSUSE may be your best bet.
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Hmm, not sure I'm scared of Gentoo - I don't know enough to be scared!
I've used SuSE in the past, it is ok.

 

How hard is it to set up Gentoo?

 



From: Arc Riley [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2008 5:27 PM
To: Labitt, Bruce
Cc: Coleman Kane; gnhlug-discuss@mail.gnhlug.org
Subject: Re: General Procedure to get ATI/DRI card running?

 

Everyone I work with who uses the radeonhd drivers uses Gentoo.

I agree with Coleman's assessment - it was said earlier in this thread
that you'd likely need to upgrade your X server, it really is ancient,
and likely Mesa too.

The output shows that the radeonhd driver does support your card and is
detecting it, but something else is going wrong down the chain.  Since
newer Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may
not even work unless you're running a semi-recent version of it.

If Gentoo scares you, the newest OpenSUSE may be your best bet.

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

Everyone I work with who uses the radeonhd drivers uses Gentoo.

I agree with Coleman's assessment - it was said earlier in this thread that
you'd likely need to upgrade your X server, it really is ancient, and likely
Mesa too.

The output shows that the radeonhd driver does support your card and is
detecting it, but something else is going wrong down the chain.  Since newer
Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may not even
work unless you're running a semi-recent version of it.

If Gentoo scares you, the newest OpenSUSE may be your best bet.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote:
> Umm, thanks for your frank assessment. 
> 
> So which is the lesser of evils - using the AMD/ATI proprietary drivers
> for 3D, or totally rebuilding my system from the ground up?  I presume
> that I will still have to mess around to get things going.  I've fooled
> around with this a few days now, I don't like wasting my time - I have
> plenty to do.  

Have you tried their proprietary drivers on your current system yet? Do
they work on such an old server?

You could always move to a Linux distro that has much newer components
to it, and start from there. The reason I posted "slackware" was just
that I've already done that route and felt it would actually be faster
to do than to shoehorn the development-class X server components into
your current system. It will be much cleaner.

If you were to just go and download all the development code for the
X.org modules and start building them, you would start to run into
compiler problems where some of the X.org headers that you have in
your /usr/include/* need to actually be removed so that they don't
override package-local versions of those headers. I don't have a
verified list of which ones they were but there are a bunch of them. So,
by trial and error you would waste immense time trying to get these
packages built for your system.

Starting from a fresh, empty base, you are more likely to have a full
working product much quicker.

> 
> If I were to do this from the ground up, which distro to choose?  Why
> slackware?  Why not Gentoo?  I suppose I can have a daily overnight
> update and recompile everything for the morning.  
> 
> I had originally wanted a relatively stable system.  It appears I can't
> get any work done with a stable system :(
> 

If you want to keep a stable system, you won't be able to easily do that
with cutting-edge hardware AND get all the cutting-edge features. This
is even beginning to be the case with Windows nowadays too (and they
have no excuse). 

From my experience, your options are:
  - Cutting edge system
  - Stable system

Choose one. :-)

In my case, I chose the first and use FreeBSD. The "cutting edge" is
"stable enough" for me, but I would never deploy a system like this onto
a bunch of office workstations. I would probably use hardware that is at
least a whole year old, and install FreeBSD 6.2 on them, after verifying
that all of the hardware has an existing track record of working well
under FreeBSD (either by buying a test system first, or researching it
online from someone else who's already bought the hardware).

> Any other solutions available?  Second opinion?  Anyone?
> 
> Bruce

Maybe it would be worth your time to investigate using the most recent
development snapshot of the xf86-video-ati driver, from its git repo? It
*might* be more compatible with older X servers, as it is at least that
old. The build/install procedure is pretty similar to what you've
already done with the radeonhd driver from what I can tell. You'll just
want to change the "radeonhd" into "radeon" in your conf file after you
build and install the driver.

> 
> -Original Message-
> From: Coleman Kane [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 09, 2008 4:37 PM
> To: Labitt, Bruce
> Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org
> Subject: RE: General Procedure to get ATI/DRI card running?
> 
> On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote:
> > Arc led me to believe that I did not have to do that yet.  He said
> that
> > the drm did not support radeonhd yet.
> > 
> > Believe me, this is more complicated than I had anticipated... :)
> > 
> > Here is the logfile
> > 
> 
> First of all, I can tell just by looking at this log output that you are
> in for a long headache. Your X server is over 2 years old, and won't be
> able to support DRI on the radeonhd. Your X server might not even
> support AIGLX on many of the drivers that will work with its older DRI
> implementation today.
> 
> The latest X server is v1.4.1, and you are using v1.1.1. The oldest one
> that will support DRI using radeonhd is v1.4.99.something, from the v1.5
> snapshots branch in the xorg-server git repository.
> 
> Basically, you are trying to use a brand new driver for a brand new
> piece of hardware with an ancient installation of X-Windows. If your
> distro at least had a v1.4+ X-server, you might be able to get by just
> by rebuilding about five modules.
> 
> Likely, you will need to rebuild almost all of X from scratch, and try
> to make sure that it doesn't accidentally bring in headers from the old
> X installation.
> 
> IOW, to get it working on your system, you are in for a wild ride. It i

RE: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote:
> Umm, thanks for your frank assessment. 
> 
> So which is the lesser of evils - using the AMD/ATI proprietary
> drivers
> for 3D, or totally rebuilding my system from the ground up?  I presume
> that I will still have to mess around to get things going.  I've
> fooled
> around with this a few days now, I don't like wasting my time - I have
> plenty to do.  
> 
> If I were to do this from the ground up, which distro to choose?  Why
> slackware?  Why not Gentoo?  I suppose I can have a daily overnight
> update and recompile everything for the morning.  
> 
> I had originally wanted a relatively stable system.  It appears I
> can't
> get any work done with a stable system :(
> 
> Any other solutions available?  Second opinion?  Anyone?

Given that Novell was contracted by AMD to work on the radeonhd driver,
you might want to go with the latest openSUSE development code.

If you want to go bleeding edge, but stick to something as close to RHEL
as possible, Fedora also tracks upstream reasonably closely, and
Fedora's development branch does have some radeonhd goodness in it too
(currently a 6/30 snap of the radeonhd driver).

I'd be surprised if the Ubuntu development branch for 8.10 doesn't have
radeonhd support too.


-- 
Jarod Wilson
[EMAIL PROTECTED]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Umm, thanks for your frank assessment. 

So which is the lesser of evils - using the AMD/ATI proprietary drivers
for 3D, or totally rebuilding my system from the ground up?  I presume
that I will still have to mess around to get things going.  I've fooled
around with this a few days now, I don't like wasting my time - I have
plenty to do.  

If I were to do this from the ground up, which distro to choose?  Why
slackware?  Why not Gentoo?  I suppose I can have a daily overnight
update and recompile everything for the morning.  

I had originally wanted a relatively stable system.  It appears I can't
get any work done with a stable system :(

Any other solutions available?  Second opinion?  Anyone?

Bruce

-Original Message-
From: Coleman Kane [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2008 4:37 PM
To: Labitt, Bruce
Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org
Subject: RE: General Procedure to get ATI/DRI card running?

On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote:
> Arc led me to believe that I did not have to do that yet.  He said
that
> the drm did not support radeonhd yet.
> 
> Believe me, this is more complicated than I had anticipated... :)
> 
> Here is the logfile
> 

First of all, I can tell just by looking at this log output that you are
in for a long headache. Your X server is over 2 years old, and won't be
able to support DRI on the radeonhd. Your X server might not even
support AIGLX on many of the drivers that will work with its older DRI
implementation today.

The latest X server is v1.4.1, and you are using v1.1.1. The oldest one
that will support DRI using radeonhd is v1.4.99.something, from the v1.5
snapshots branch in the xorg-server git repository.

Basically, you are trying to use a brand new driver for a brand new
piece of hardware with an ancient installation of X-Windows. If your
distro at least had a v1.4+ X-server, you might be able to get by just
by rebuilding about five modules.

Likely, you will need to rebuild almost all of X from scratch, and try
to make sure that it doesn't accidentally bring in headers from the old
X installation.

IOW, to get it working on your system, you are in for a wild ride. It is
probably easier to just install Slackware and start from scratch.

Furthermore, if you do get all of the latest X stuff, you'll need to
disable 2D acceleration in order to allow 3D acceleration to work on the
latest driver IIRC.

I strongly suggest you get in touch with the radeonhd mailing list as
well.

> X Window System Version 7.1.1
> Release Date: 12 May 2006
> X Protocol Version 11, Revision 0, Release 7.1.1
> Build Operating System: Linux 2.6.18-8.1.8.el5 x86_64 Red Hat, Inc.
> Current Operating System: Linux xxx..xxx 2.6.18-92.1.6.el5xen #1
SMP
> Wed Jun 25 12:56:52 EDT 2008 x86_64
> Build Date: 12 June 2008
> Build ID: xorg-x11-server 1.1.1-48.41.el5_2.1 
>   Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> Module Loader present
> Markers: (--) probed, (**) from config file, (==) default setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul  9 15:02:06 2008

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Coleman Kane]

0)
> (II) RADEONHD(0): PCI FB Address (BAR) is at 0xC000 while card
> Internal Address is 0xE000
> (II) RADEONHD(0): Mapped FB at 0x2b66ffa81000 (size 0x1000)
> (II) RADEONHD(0): Using 3495 scanlines of offscreen memory
> (II) RADEONHD(0): Using XFree86 Acceleration Architecture (XAA)
>   Screen to screen bit blits
>   Solid filled rectangles
>   8x8 mono pattern filled rectangles
>   Indirect CPU to Screen color expansion
>   Solid Lines
>   Scanline Image Writes
>   Offscreen Pixmaps
>   Setting up tile and stipple cache:
>   32 128x128 slots
>   32 256x256 slots
>   14 512x512 slots
> (==) RADEONHD(0): Backing store disabled
> (==) RADEONHD(0): Silken mouse enabled
> (II) RADEONHD(0): Setting up "1920x1200" ([EMAIL PROTECTED])
> (II) RADEONHD(0): Shutting down DAC A
> (II) RADEONHD(0): Shutting down DAC B
> (II) RADEONHD(0): Shutting down TMDS B
> (II) RADEONHD(0): Using HW cursor
> (==) RandR enabled
> (II) Initializing built-in extension MIT-SHM
> (II) Initializing built-in extension XInputExtension
> (II) Initializing built-in extension XTEST
> (II) Initializing built-in extension XKEYBOARD
> (II) Initializing built-in extension XC-APPGROUP
> (II) Initializing built-in extension SECURITY
> (II) Initializing built-in extension XINERAMA
> (II) Initializing built-in extension XFIXES
> (II) Initializing built-in extension XFree86-Bigfont
> (II) Initializing built-in extension RENDER
> (II) Initializing built-in extension RANDR
> (II) Initializing built-in extension COMPOSITE
> (II) Initializing built-in extension DAMAGE
> (II) Initializing built-in extension XEVIE
> (EE) AIGLX: DRI module not loaded
> (II) Loading local sub module "GLcore"
> (II) LoadModule: "GLcore"
> (II) Loading /usr/lib64/xorg/modules/extensions/libGLcore.so
> (II) Module GLcore: vendor="X.Org Foundation"
>   compiled for 7.1.1, module version = 1.0.0
>   ABI class: X.Org Server Extension, version 0.3
> (II) GLX: Initialized MESA-PROXY GL provider for screen 0
> (**) Option "CoreKeyboard"
> (**) Keyboard0: Core Keyboard
> (**) Option "Protocol" "standard"
> (**) Keyboard0: Protocol: standard
> (**) Option "AutoRepeat" "500 30"
> (**) Option "XkbRules" "xorg"
> (**) Keyboard0: XkbRules: "xorg"
> (**) Option "XkbModel" "pc105"
> (**) Keyboard0: XkbModel: "pc105"
> (**) Option "XkbLayout" "us"
> (**) Keyboard0: XkbLayout: "us"
> (**) Option "CustomKeycodes" "off"
> (**) Keyboard0: CustomKeycodes disabled
> (WW) : No Device specified, looking for one...
> (II) : Setting Device option to "/dev/input/mice"
> (--) : Device: "/dev/input/mice"
> (==) : Protocol: "Auto"
> (**) Option "CorePointer"
> (**) : Core Pointer
> (==) : Emulate3Buttons, Emulate3Timeout: 50
> (**) : ZAxisMapping: buttons 4 and 5
> (**) : Buttons: 9
> (II) XINPUT: Adding extended input device "" (type:
> MOUSE)
> (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
> (--) : PnP-detected protocol: "ExplorerPS/2"
> (II) : ps2EnableDataReporting: succeeded
> 
> -Original Message-
> From: Coleman Kane [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 09, 2008 3:25 PM
> To: Labitt, Bruce
> Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org
> Subject: RE: General Procedure to get ATI/DRI card running?
> 
> On Wed, 2008-07-09 at 15:13 -0400, Labitt, Bruce wrote:
> > No joy so far.  Still getting Mesa GLX Indirect.  Any other ideas?
> > 
> > Does the order in the file matter?
> 
> Did you update to the latest development versions of mesa, drm,
> dri2proto, xorg-server, and friends?
> 
> Also, you need to enable AIGLX in your xserver.
> 
> If you post your /var/log/Xorg.0.log after running an unsuccessful X
> session, it will be easier to diagnose the problem.
> 
> > 
> > 
> > From: Arc Riley [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, July 09, 2008 2:06 PM
> > To: Labitt, Bruce
> > Cc: Greater NH Linux User Group
> > Subject: Re: General Procedure to get ATI/DRI card running?
> > 
> > Looks like you're missing the glx module, based on your paste not
> including it.
> > 
> > Section "Module"
> > Load  "glx"
> > 
> 
-- 
Coleman Kane


signature.asc
Description: This is a digitally signed message part
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

1 0   0xfec0 - 0xfecf (0x10) IX[B]
[29] -1 0   0xfe30 - 0xfe33 (0x4) IX[B]
[30] -1 0   0xfe20 - 0xfe27 (0x8) IX[B]
[31] -1 0   0xfe10 - 0xfe13 (0x4) IX[B]
[32] -1 0   0xfe00 - 0xfe07 (0x8) IX[B]
[33] -1 0   0xff40 - 0xff5f (0x20) IX[B]
[34] -1 0   0xff60 - 0xff7f (0x20) IX[B]
[35] -1 0   0xff80 - 0xff9f (0x20) IX[B]
[36] -1 0   0xff00 - 0xff1f (0x20) IX[B]
[37] -1 0   0xff20 - 0xff3f (0x20) IX[B]
[38] -1 0   0xdc00 - 0xdcff (0x100) IX[B](B)
(II) RADEONHD(0): Mapped IO at 0x2b66fefc9000 (size 0x0001)
(WW) RADEONHD(0): Failed to set up write-combining range
(0xc000,0x1000)
(II) RADEONHD(0): PCI FB Address (BAR) is at 0xC000 while card
Internal Address is 0xE000
(II) RADEONHD(0): Mapped FB at 0x2b66ffa81000 (size 0x1000)
(II) RADEONHD(0): Using 3495 scanlines of offscreen memory
(II) RADEONHD(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Scanline Image Writes
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
32 256x256 slots
14 512x512 slots
(==) RADEONHD(0): Backing store disabled
(==) RADEONHD(0): Silken mouse enabled
(II) RADEONHD(0): Setting up "1920x1200" ([EMAIL PROTECTED])
(II) RADEONHD(0): Shutting down DAC A
(II) RADEONHD(0): Shutting down DAC B
(II) RADEONHD(0): Shutting down TMDS B
(II) RADEONHD(0): Using HW cursor
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(EE) AIGLX: DRI module not loaded
(II) Loading local sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib64/xorg/modules/extensions/libGLcore.so
(II) Module GLcore: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.3
(II) GLX: Initialized MESA-PROXY GL provider for screen 0
(**) Option "CoreKeyboard"
(**) Keyboard0: Core Keyboard
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Keyboard0: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "us"
(**) Keyboard0: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(WW) : No Device specified, looking for one...
(II) : Setting Device option to "/dev/input/mice"
(--) : Device: "/dev/input/mice"
(==) : Protocol: "Auto"
(**) Option "CorePointer"
(**) : Core Pointer
(==) : Emulate3Buttons, Emulate3Timeout: 50
(**) : ZAxisMapping: buttons 4 and 5
(**) : Buttons: 9
(II) XINPUT: Adding extended input device "" (type:
MOUSE)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(--) : PnP-detected protocol: "ExplorerPS/2"
(II) : ps2EnableDataReporting: succeeded

-Original Message-
From: Coleman Kane [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2008 3:25 PM
To: Labitt, Bruce
Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org
Subject: RE: General Procedure to get ATI/DRI card running?

On Wed, 2008-07-09 at 15:13 -0400, Labitt, Bruce wrote:
> No joy so far.  Still getting Mesa GLX Indirect.  Any other ideas?
> 
> Does the order in the file matter?

Did you update to the latest development versions of mesa, drm,
dri2proto, xorg-server, and friends?

Also, you need to enable AIGLX in your xserver.

If you post your /var/log/Xorg.0.log after running an unsuccessful X
session, it will be easier to diagnose the problem.

> 
> 
> From: Arc Riley [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 09, 2008 2:06 PM
> To: Labitt, Bruce
> Cc: Greater NH Linux User Group
> Subject: Re: General Procedure to get ATI/DRI card running?
> 
> Looks like you're missing the glx module, based on your paste not
including it.
> 
> Section "Module"
> Load  "glx"
> 

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-09 at 15:13 -0400, Labitt, Bruce wrote:
> No joy so far.  Still getting Mesa GLX Indirect.  Any other ideas?
> 
> Does the order in the file matter?

Did you update to the latest development versions of mesa, drm,
dri2proto, xorg-server, and friends?

Also, you need to enable AIGLX in your xserver.

If you post your /var/log/Xorg.0.log after running an unsuccessful X
session, it will be easier to diagnose the problem.

> 
> 
> From: Arc Riley [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 09, 2008 2:06 PM
> To: Labitt, Bruce
> Cc: Greater NH Linux User Group
> Subject: Re: General Procedure to get ATI/DRI card running?
> 
> Looks like you're missing the glx module, based on your paste not including 
> it.
> 
> Section "Module"
> Load  "glx"
> 
> In the future I'll be sure to ask what distro you're running before 
> recommending hardware.  Apparently everyone that isn't running Gentoo or 
> another up-to-date distro is a second-class citizen left to toil in the 
> fields if they want anything even remotely new.
> 
> # emerge -av xf86-video-radeonhd 
> On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote:
> Arc,
>  
> My kernel is 2.6.18-92.1.6.el5
>  
> in /etc/X11/xorg.conf I have
>  
> Section "Device"
>   Identifier "Videocard0"
>   Driver "radeonhd"
> EndSection
>  
> Section "Screen"
>   Identifier "Screen0"
>   Device "Videocard0"
>   DefaultDepth 24
>   SubSection "Display"
>  Viewport 0 0
>  Depth24
>   EndSubSection
> EndSubSection
>  
> Regards,
> Bruce
> 
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
-- 
Coleman Kane


signature.asc
Description: This is a digitally signed message part
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

No joy so far.  Still getting Mesa GLX Indirect.  Any other ideas?

Does the order in the file matter?


From: Arc Riley [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2008 2:06 PM
To: Labitt, Bruce
Cc: Greater NH Linux User Group
Subject: Re: General Procedure to get ATI/DRI card running?

Looks like you're missing the glx module, based on your paste not including it.

Section "Module"
    Load  "glx"

In the future I'll be sure to ask what distro you're running before 
recommending hardware.  Apparently everyone that isn't running Gentoo or 
another up-to-date distro is a second-class citizen left to toil in the fields 
if they want anything even remotely new.

# emerge -av xf86-video-radeonhd 
On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote:
Arc,
 
My kernel is 2.6.18-92.1.6.el5
 
in /etc/X11/xorg.conf I have
 
Section "Device"
  Identifier "Videocard0"
  Driver "radeonhd"
EndSection
 
Section "Screen"
  Identifier "Screen0"
  Device "Videocard0"
  DefaultDepth 24
  SubSection "Display"
 Viewport 0 0
 Depth    24
  EndSubSection
EndSubSection
 
Regards,
Bruce

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Wed, 2008-07-09 at 14:05 -0400, Arc Riley wrote:
> In the future I'll be sure to ask what distro you're running before
> recommending hardware.  Apparently everyone that isn't running Gentoo
> or another up-to-date distro is a second-class citizen left to toil in
> the fields if they want anything even remotely new.

How can Gentoo claim to be up-to-date when 2008.0 released just last
week comes with kernel 2.6.24, while Fedora 9 released about a month ago
with 2.6.25...

/me ducks and runs... ;)


-- 
Jarod Wilson
[EMAIL PROTECTED]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

Looks like you're missing the glx module, based on your paste not including
it.

Section "Module"
Load  "glx"

In the future I'll be sure to ask what distro you're running before
recommending hardware.  Apparently everyone that isn't running Gentoo or
another up-to-date distro is a second-class citizen left to toil in the
fields if they want anything even remotely new.

# emerge -av xf86-video-radeonhd

On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]>
wrote:

>  Arc,
>
>
>
> My kernel is 2.6.18-92.1.6.el5
>
>
>
> in /etc/X11/xorg.conf I have
>
>
>
> Section "Device"
>
>   Identifier "Videocard0"
>
>   Driver "radeonhd"
>
> EndSection
>
>
>
> Section "Screen"
>
>   Identifier "Screen0"
>
>   Device "Videocard0"
>
>   DefaultDepth 24
>
>   SubSection "Display"
>
> Viewport 0 0
>
> Depth24
>
>   EndSubSection
>
> EndSubSection
>
>
>
> Regards,
>
> Bruce
>
>
>  --
>
> *From:* Arc Riley [mailto:[EMAIL PROTECTED]
> *Sent:* Wednesday, July 09, 2008 1:36 PM
>
> *To:* Labitt, Bruce
> *Cc:* Greater NH Linux User Group
> *Subject:* Re: General Procedure to get ATI/DRI card running?
>
>
>
> It could be any number of things, from the glx module being turned off in
> your xorg.conf, or the radeonhd driver not being loaded, or something else
> entirely.
>
> I know nothing about the tool you used to generate your xorg.conf and thus
> don't know what it tends to do.  Have you looked at the xorg.conf and
> verified that it's set to use "radeonhd"?
>
> BTW, I just was told that if you have an updated kernel, your card may
> already be supported by the stock Linux "radeon" DRM driver.  Easier to wait
> on that for your distro to catch up and focus on getting GLX for now.
>
> On Wed, Jul 9, 2008 at 1:30 PM, Labitt, Bruce <
> [EMAIL PROTECTED]> wrote:
>
> Arc,
>
>
>
> How does one change that?  Sorry to be such a noob.
>
>
>
> Regards,
>
> Bruce
>
>
>  --
>
> *From:* Arc Riley [mailto:[EMAIL PROTECTED]
> *Sent:* Wednesday, July 09, 2008 1:22 PM
> *To:* Labitt, Bruce
>
>
> *Cc:* Greater NH Linux User Group
> *Subject:* Re: General Procedure to get ATI/DRI card running?
>
>
>
> This is the part you need to fix:
>
> OpenGL renderer string: Mesa GLX Indirect
>
> If you can get it to use the radeonhd driver, even over standard GLX, it'll
> be accelerated.  DRM speeds things up a bit by allowing the application to
> render directly through the kerner rather than sending rendering through the
> X server.
>
> On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce <
> [EMAIL PROTECTED]> wrote:
>
> $ glxinfo
>
> name of display: :0.0
>
> display: :0  screen: 0
>
> direct rendering: No
>
> server glx vendor string: SGI
>
> server glx version string: 1.2
>
> server glx extensions:
>
> GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
>
> GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
> GLX_OML_swap_method,
>
> GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
>
> GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
>
> client glx vendor string: SGI
>
> client glx version string: 1.4
>
> client glx extensions:
>
> GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
>
> GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
>
> GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
>
> GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
>
> GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
>
> GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
>
> GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
>
> GLX version: 1.2
>
> GLX extensions:
>
> GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
>
> GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
>
> GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample,
>
> GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap
>
> OpenGL vendor string: Mesa project: www.mesa3d.org
>
> OpenGL renderer string: Mesa GLX Indirect
>
> OpenGL version string: 1.2 (1.5 Mesa 6.5.1)
>
> OpenGL extensions:
>
> GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture,
>
> GL_ARB_point_parameters, G

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

It could be any number of things, from the glx module being turned off in
your xorg.conf, or the radeonhd driver not being loaded, or something else
entirely.

I know nothing about the tool you used to generate your xorg.conf and thus
don't know what it tends to do.  Have you looked at the xorg.conf and
verified that it's set to use "radeonhd"?

BTW, I just was told that if you have an updated kernel, your card may
already be supported by the stock Linux "radeon" DRM driver.  Easier to wait
on that for your distro to catch up and focus on getting GLX for now.

On Wed, Jul 9, 2008 at 1:30 PM, Labitt, Bruce <[EMAIL PROTECTED]>
wrote:

>  Arc,
>
>
>
> How does one change that?  Sorry to be such a noob.
>
>
>
> Regards,
>
> Bruce
>
>
>  --
>
> *From:* Arc Riley [mailto:[EMAIL PROTECTED]
> *Sent:* Wednesday, July 09, 2008 1:22 PM
> *To:* Labitt, Bruce
>
> *Cc:* Greater NH Linux User Group
> *Subject:* Re: General Procedure to get ATI/DRI card running?
>
>
>
> This is the part you need to fix:
>
> OpenGL renderer string: Mesa GLX Indirect
>
> If you can get it to use the radeonhd driver, even over standard GLX, it'll
> be accelerated.  DRM speeds things up a bit by allowing the application to
> render directly through the kerner rather than sending rendering through the
> X server.
>
>  On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce <
> [EMAIL PROTECTED]> wrote:
>
> $ glxinfo
>
> name of display: :0.0
>
> display: :0  screen: 0
>
> direct rendering: No
>
> server glx vendor string: SGI
>
> server glx version string: 1.2
>
> server glx extensions:
>
> GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
>
> GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
> GLX_OML_swap_method,
>
> GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
>
> GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
>
> client glx vendor string: SGI
>
> client glx version string: 1.4
>
> client glx extensions:
>
> GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
>
> GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
>
> GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
>
> GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
>
> GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
>
> GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
>
> GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
>
> GLX version: 1.2
>
> GLX extensions:
>
> GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
>
> GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
>
> GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample,
>
> GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap
>
> OpenGL vendor string: Mesa project: www.mesa3d.org
>
> OpenGL renderer string: Mesa GLX Indirect
>
> OpenGL version string: 1.2 (1.5 Mesa 6.5.1)
>
> OpenGL extensions:
>
> GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture,
>
> GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow,
>
> GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
>
> GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
>
> GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
>
> GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
>
> GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
>
> GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
>
> GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op,
>
> GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
>
> GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
>
> GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
> GL_EXT_packed_pixels,
>
> GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
>
> GL_EXT_secondary_color, GL_EXT_separate_specular_color,
>
> GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture,
>
> GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
>
> GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
>
> GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
> GL_EXT_texture_object,
>
> GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
>
> GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once,
>
> GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat,
>
> GL_INGR_blend_func_separ

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Arc,

 

How does one change that?  Sorry to be such a noob.

 

Regards,

Bruce

 



From: Arc Riley [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 09, 2008 1:22 PM
To: Labitt, Bruce
Cc: Greater NH Linux User Group
Subject: Re: General Procedure to get ATI/DRI card running?

 

This is the part you need to fix:

OpenGL renderer string: Mesa GLX Indirect

If you can get it to use the radeonhd driver, even over standard GLX,
it'll be accelerated.  DRM speeds things up a bit by allowing the
application to render directly through the kerner rather than sending
rendering through the X server.



On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:

$ glxinfo

name of display: :0.0

display: :0  screen: 0

direct rendering: No

server glx vendor string: SGI

server glx version string: 1.2

server glx extensions:

GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 

GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_OML_swap_method, 

GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,


GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer

client glx vendor string: SGI

client glx version string: 1.4

client glx extensions:

GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_import_context, 

GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_MESA_allocate_memory, 

GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 

GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, 

GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,


GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap

GLX version: 1.2

GLX extensions:

GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_import_context, 

GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_MESA_copy_sub_buffer, 

GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, 

GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap

OpenGL vendor string: Mesa project: www.mesa3d.org

OpenGL renderer string: Mesa GLX Indirect

OpenGL version string: 1.2 (1.5 Mesa 6.5.1)

OpenGL extensions:

GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, 

GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, 

GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 

GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 

GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 

GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 

GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 

GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr,
GL_EXT_bgra, 

GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, 

GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,


GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 

GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, 

GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, 

GL_EXT_secondary_color, GL_EXT_separate_specular_color, 

GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, 

GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, 

GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 

GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, 

GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_APPLE_packed_pixels, 

GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, 

GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, 

GL_INGR_blend_func_separate, GL_MESA_pack_invert,
GL_MESA_ycbcr_texture, 

GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, 

GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, 

GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 

GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, 

GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays

 

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav

 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat

--

0x23 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None

0x24 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None

0x25 24 tc  0 32  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x26 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x27 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None

0x28 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None

0x29 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x2a 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x42 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon

 

 

A few more months!!!

-Bruce

 

___

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

0x29 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
>
> 0x2a 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
>
> 0x42 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon
>
>
>
>
>
> A few more months!!!
>
> -Bruce
>
>
>  --
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Arc Riley
> *Sent:* Tuesday, July 08, 2008 10:56 PM
> *To:* Bruce Labitt
> *Cc:* Greater NH Linux User Group
> *Subject:* Re: General Procedure to get ATI/DRI card running?
>
>
>
> ah sorry looks like radeonhd DRM isn't ready yet.  a few more months.
>
> indirect rendering (using GLX instead of DRI) is usually good enough, you
> should compile the DRM kernel module when it's ready though.
>
> so what does your glxinfo output look like?
>
> On Tue, Jul 8, 2008 at 10:33 PM, Bruce Labitt <[EMAIL PROTECTED]>
> wrote:
>
> So how is the DRM kernel module made active?
>
> Arc Riley wrote:
>
> Since you're no longer under the warm and fuzzy management of your distro,
> it's possible something related to DRI may be disabled or lacking
> permissions.
>
> Also note you'll need the DRM (Direct Rendering Manager) kernel module
> active.
>
> when glxinfo says that your direct rendering is enabled, you're golden.
>
> On Tue, Jul 8, 2008 at 9:23 PM, Bruce Labitt <[EMAIL PROTECTED] [EMAIL PROTECTED]>> wrote:
>
>Jarod Wilson wrote:
>> On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
>>
>>> Load Module: "radeonhd"
>>>
>>> Warning, couldn't open "radeonhd"
>>>
>>> Failed to load module "radeonhd" (module does not exist, 0)
>>>
>>
>>
>>> So what extra steps do I take after building radeonhd?
>>>
>>
>> Install it where your X server is looking for modules?
>>
>> For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
>> s/lib64/lib/.
>>
>>
>>
>>
>>
>
>Hmm, radical idea :)  That helped!
>After much breath holding / restarting of x, it appears the
>radeonhd driver is installed.
>
>Of course, it doesn't seem to change the results on glxgears.
> glxinfo looks different now.
>
>So on to configuring radeonhd...
>
>-Bruce
>
>___
>gnhlug-discuss mailing list
>
>gnhlug-discuss@mail.gnhlug.org <mailto:gnhlug-discuss@mail.gnhlug.org>
>
>
>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
>
>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

$ glxinfo

name of display: :0.0

display: :0  screen: 0

direct rendering: No

server glx vendor string: SGI

server glx version string: 1.2

server glx extensions:

GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 

GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_OML_swap_method, 

GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,


GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer

client glx vendor string: SGI

client glx version string: 1.4

client glx extensions:

GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_import_context, 

GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_MESA_allocate_memory, 

GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 

GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, 

GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,


GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap

GLX version: 1.2

GLX extensions:

GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_import_context, 

GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_MESA_copy_sub_buffer, 

GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, 

GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap

OpenGL vendor string: Mesa project: www.mesa3d.org

OpenGL renderer string: Mesa GLX Indirect

OpenGL version string: 1.2 (1.5 Mesa 6.5.1)

OpenGL extensions:

GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, 

GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, 

GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 

GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 

GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 

GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 

GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 

GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr,
GL_EXT_bgra, 

GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, 

GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,


GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 

GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, 

GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, 

GL_EXT_secondary_color, GL_EXT_separate_specular_color, 

GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, 

GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, 

GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 

GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, 

GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_APPLE_packed_pixels, 

GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, 

GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, 

GL_INGR_blend_func_separate, GL_MESA_pack_invert,
GL_MESA_ycbcr_texture, 

GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, 

GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, 

GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 

GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, 

GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays

 

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav

 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat

--

0x23 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None

0x24 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None

0x25 24 tc  0 32  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x26 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x27 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None

0x28 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None

0x29 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x2a 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None

0x42 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon

 

 

A few more months!!!

-Bruce

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arc Riley
Sent: Tuesday, July 08, 2008 10:56 PM
To: Bruce Labitt
Cc: Greater NH Linux User Group
Subject: Re: General Procedure to get ATI/DRI card running?

 

ah sorry looks like radeonhd DRM isn't ready yet.  a few more months.

indirect rendering (using GLX instead of DRI) is usually good enough,
you should compile the DRM kernel module when it's ready though.

so what does your glxinfo output look like?

On Tue, Jul 8, 2008 at 10:33 PM, Bruce Labitt <[EMAIL PROTECTED]>
wrote:

So how is the DRM kernel module made active?

Arc Riley wrote:

Since you're no longer under the warm and fuzzy management of your
distro, it

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

ah sorry looks like radeonhd DRM isn't ready yet.  a few more months.

indirect rendering (using GLX instead of DRI) is usually good enough, you
should compile the DRM kernel module when it's ready though.

so what does your glxinfo output look like?

On Tue, Jul 8, 2008 at 10:33 PM, Bruce Labitt <[EMAIL PROTECTED]>
wrote:

> So how is the DRM kernel module made active?
>
> Arc Riley wrote:
>
>> Since you're no longer under the warm and fuzzy management of your distro,
>> it's possible something related to DRI may be disabled or lacking
>> permissions.
>>
>> Also note you'll need the DRM (Direct Rendering Manager) kernel module
>> active.
>>
>> when glxinfo says that your direct rendering is enabled, you're golden.
>>
>> On Tue, Jul 8, 2008 at 9:23 PM, Bruce Labitt <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Jarod Wilson wrote:
>>> On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
>>>
>>>> Load Module: "radeonhd"
>>>>
>>>> Warning, couldn't open "radeonhd"
>>>>
>>>> Failed to load module "radeonhd" (module does not exist, 0)
>>>>
>>>
>>>
>>>> So what extra steps do I take after building radeonhd?
>>>>
>>>
>>> Install it where your X server is looking for modules?
>>>
>>> For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
>>> s/lib64/lib/.
>>>
>>>
>>>
>>>
>>>
>>
>>Hmm, radical idea :)  That helped!
>>After much breath holding / restarting of x, it appears the
>>radeonhd driver is installed.
>>
>>Of course, it doesn't seem to change the results on glxgears.
>> glxinfo looks different now.
>>
>>So on to configuring radeonhd...
>>
>>-Bruce
>>
>>___
>>gnhlug-discuss mailing list
>>gnhlug-discuss@mail.gnhlug.org 
>>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>>
>>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Bruce Labitt]

So how is the DRM kernel module made active?

Arc Riley wrote:
> Since you're no longer under the warm and fuzzy management of your 
> distro, it's possible something related to DRI may be disabled or 
> lacking permissions.
>
> Also note you'll need the DRM (Direct Rendering Manager) kernel module 
> active.
>
> when glxinfo says that your direct rendering is enabled, you're golden.
>
> On Tue, Jul 8, 2008 at 9:23 PM, Bruce Labitt <[EMAIL PROTECTED] 
> > wrote:
>
> Jarod Wilson wrote:
> > On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
> >
> >> Load Module: "radeonhd"
> >>
> >> Warning, couldn't open "radeonhd"
> >>
> >> Failed to load module "radeonhd" (module does not exist, 0)
> >>
> >
> >
> >> So what extra steps do I take after building radeonhd?
> >>
> >
> > Install it where your X server is looking for modules?
> >
> > For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
> > s/lib64/lib/.
> >
> >
> >
> >
> >
>
> Hmm, radical idea :)  That helped!
> After much breath holding / restarting of x, it appears the
> radeonhd driver is installed.
>
> Of course, it doesn't seem to change the results on glxgears.
>  glxinfo looks different now.
>
> So on to configuring radeonhd...
>
> -Bruce
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org 
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

Since you're no longer under the warm and fuzzy management of your distro,
it's possible something related to DRI may be disabled or lacking
permissions.

Also note you'll need the DRM (Direct Rendering Manager) kernel module
active.

when glxinfo says that your direct rendering is enabled, you're golden.

On Tue, Jul 8, 2008 at 9:23 PM, Bruce Labitt <[EMAIL PROTECTED]>
wrote:

> Jarod Wilson wrote:
> > On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
> >
> >> Load Module: "radeonhd"
> >>
> >> Warning, couldn't open "radeonhd"
> >>
> >> Failed to load module "radeonhd" (module does not exist, 0)
> >>
> >
> >
> >> So what extra steps do I take after building radeonhd?
> >>
> >
> > Install it where your X server is looking for modules?
> >
> > For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
> > s/lib64/lib/.
> >
> >
> >
> >
> >
>
> Hmm, radical idea :)  That helped!
> After much breath holding / restarting of x, it appears the radeonhd driver
> is installed.
>
> Of course, it doesn't seem to change the results on glxgears.  glxinfo
> looks different now.
>
> So on to configuring radeonhd...
>
> -Bruce
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Bruce Labitt]

Jarod Wilson wrote:
> On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
>   
>> Load Module: "radeonhd"
>>
>> Warning, couldn't open "radeonhd"
>>
>> Failed to load module "radeonhd" (module does not exist, 0)
>> 
>
>   
>> So what extra steps do I take after building radeonhd?
>> 
>
> Install it where your X server is looking for modules?
>
> For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
> s/lib64/lib/.
>
>
>
>
>   

Hmm, radical idea :)  That helped!
After much breath holding / restarting of x, it appears the radeonhd driver is 
installed.

Of course, it doesn't seem to change the results on glxgears.  glxinfo looks 
different now.

So on to configuring radeonhd...

-Bruce

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Tue, 2008-07-08 at 16:03 -0400, Labitt, Bruce wrote:
> Load Module: "radeonhd"
> 
> Warning, couldn't open "radeonhd"
> 
> Failed to load module "radeonhd" (module does not exist, 0)

> So what extra steps do I take after building radeonhd?

Install it where your X server is looking for modules?

For 64-bit EL5, /usr/lib64/xorg/modules/drivers, for 32-bit,
s/lib64/lib/.



-- 
Jarod Wilson
[EMAIL PROTECTED]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Labitt,
Bruce
Sent: Tuesday, July 08, 2008 3:32 PM
To: Arc Riley
Cc: Greater NH Linux User Group
Subject: RE: General Procedure to get ATI/DRI card running?

 

Hi Arc,

 

I tried changing xorg.conf to "radeonhd".  That hosed things up.  

 

I built radeonhd from the instructions on wiki.x.org/wiki/radeonhd

 

If I use the following:

 

#system-config-display --noui --set-driver=radeonhd

 

Is that going to be ok?

 

Thanks!

Bruce

 



 

To answer my own question, NO.  

 

I got an X error.

 

Load Module: "radeonhd"

Warning, couldn't open "radeonhd"

Failed to load module "radeonhd" (module does not exist, 0)

 

So what extra steps do I take after building radeonhd?

 

-Bruce

 

 

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Hi Arc,

 

I tried changing xorg.conf to "radeonhd".  That hosed things up.  

 

I built radeonhd from the instructions on wiki.x.org/wiki/radeonhd

 

If I use the following:

 

#system-config-display --noui --set-driver=radeonhd

 

Is that going to be ok?

 

Thanks!

Bruce

 



From: Arc Riley [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 08, 2008 2:55 PM
To: Labitt, Bruce
Cc: Ben Scott; Greater NH Linux User Group
Subject: Re: General Procedure to get ATI/DRI card running?

 

are you using the radeonhd driver?

On Tue, Jul 8, 2008 at 10:52 AM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:

Subject: Re: General Procedure to get ATI/DRI card running?

On Mon, Jul 7, 2008 at 10:21 AM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:
> #system-config-display --noui --set-driver=radeon_tp
>
> If this for some reason hoses things, how does one recover back to the
> baseline Intel mobo graphics?

 Before you run the above command, make a backup of your existing
config file:

cd /etc/X11
cp xorg.conf intel.xorg.conf

 Then, if you need to revert, copy the backup over the newly damaged
file:

cd /etc/X11
cp intel.xorg.conf xorg.conf

-- Ben
___

[Labitt, Bruce] Thanks Ben.  I'm now running on the radeon x1650 with
dvi on my monitor.

Perhaps this question is more to Arc.

I still am having some trouble getting going.  I'm not quite sure what
to try next.  I tried downloading driconf-0.9.1 to "configure" my 3d
stuff.  When I run it I get

unknown chip id 0x71c1, can't guess.
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

Sounds like I still need to configure stuff...

Any help would be greatly appreciated!

I also tried playing with gluplot which supposedly uses opengl for
rendering.  I have no idea what format for the data files are required.
Anyone play with that?

-Bruce



___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

 

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

are you using the radeonhd driver?

On Tue, Jul 8, 2008 at 10:52 AM, Labitt, Bruce <[EMAIL PROTECTED]>
wrote:

> Subject: Re: General Procedure to get ATI/DRI card running?
>
> On Mon, Jul 7, 2008 at 10:21 AM, Labitt, Bruce
> <[EMAIL PROTECTED]> wrote:
> > #system-config-display --noui --set-driver=radeon_tp
> >
> > If this for some reason hoses things, how does one recover back to the
> > baseline Intel mobo graphics?
>
>  Before you run the above command, make a backup of your existing
> config file:
>
> cd /etc/X11
> cp xorg.conf intel.xorg.conf
>
>  Then, if you need to revert, copy the backup over the newly damaged
> file:
>
> cd /etc/X11
> cp intel.xorg.conf xorg.conf
>
> -- Ben
> ___
>
> [Labitt, Bruce] Thanks Ben.  I'm now running on the radeon x1650 with
> dvi on my monitor.
>
> Perhaps this question is more to Arc.
>
> I still am having some trouble getting going.  I'm not quite sure what
> to try next.  I tried downloading driconf-0.9.1 to "configure" my 3d
> stuff.  When I run it I get
>
> unknown chip id 0x71c1, can't guess.
> libGL warning: 3D driver returned no fbconfigs.
> libGL error: InitDriver failed
> libGL error: reverting to (slow) indirect rendering
>
> Sounds like I still need to configure stuff...
>
> Any help would be greatly appreciated!
>
> I also tried playing with gluplot which supposedly uses opengl for
> rendering.  I have no idea what format for the data files are required.
> Anyone play with that?
>
> -Bruce
>
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Subject: Re: General Procedure to get ATI/DRI card running?

On Mon, Jul 7, 2008 at 10:21 AM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:
> #system-config-display --noui --set-driver=radeon_tp
>
> If this for some reason hoses things, how does one recover back to the
> baseline Intel mobo graphics?

  Before you run the above command, make a backup of your existing
config file:

cd /etc/X11
cp xorg.conf intel.xorg.conf

  Then, if you need to revert, copy the backup over the newly damaged
file:

cd /etc/X11
cp intel.xorg.conf xorg.conf

-- Ben
___

[Labitt, Bruce] Thanks Ben.  I'm now running on the radeon x1650 with
dvi on my monitor.

Perhaps this question is more to Arc.  

I still am having some trouble getting going.  I'm not quite sure what
to try next.  I tried downloading driconf-0.9.1 to "configure" my 3d
stuff.  When I run it I get

unknown chip id 0x71c1, can't guess.
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

Sounds like I still need to configure stuff...

Any help would be greatly appreciated!

I also tried playing with gluplot which supposedly uses opengl for
rendering.  I have no idea what format for the data files are required.
Anyone play with that?

-Bruce


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Ben Scott]

On Mon, Jul 7, 2008 at 10:21 AM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:
> #system-config-display --noui --set-driver=radeon_tp
>
> If this for some reason hoses things, how does one recover back to the
> baseline Intel mobo graphics?

  Before you run the above command, make a backup of your existing config file:

cd /etc/X11
cp xorg.conf intel.xorg.conf

  Then, if you need to revert, copy the backup over the newly damaged file:

cd /etc/X11
cp intel.xorg.conf xorg.conf

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

Hi David,

I think you sent me an email on howto to convert from one video card to
the other.  I only have found a hard copy.  For some reason, the e-copy
is not to be found - might be on my home machine.

I now have SL5.2 installed.

If I recall correctly one does

#system-config-display --noui --set-driver=radeon_tp

If this for some reason hoses things, how does one recover back to the
baseline Intel mobo graphics?

Thanks,
Bruce

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David W.
Aquilina
Sent: Tuesday, July 01, 2008 6:47 PM
To: gnhlug-discuss@mail.gnhlug.org
Subject: Re: General Procedure to get ATI/DRI card running?

On Tue, Jul 01, 2008 at 05:19:24PM -0400, Labitt, Bruce wrote:
> I just got an ATI/AMD Radeon X1650 Pro video card to try to replace
the
> onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.

I'm not sure how closely SL follows CentOS/RHEL, but RHEL 5.2 introduced
the 'radeon_tp' driver ("tech preview") with experimental support for
the R500/R600-based cards. 

-David

-- 
David W. Aquilina
[EMAIL PROTECTED]
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-02 at 09:38 -0400, Jarod Wilson wrote:
> On Wed, 2008-07-02 at 09:12 -0400, Coleman Kane wrote:
> > It is really important to understand, though, that the X.org project
> > is
> > really one without a "home" or "owner". The X Consortium (x.org)
> > really
> > only committed to provide some hosting, and maintain a central
> > repository of protocol, format, and other project-related standards
> > and
> > specifications. Through its history as X.org and XFree86, it has never
> > gotten significant support from the hardware vendors that it is
> > expected
> > to support. Support for 3Dfx hardware, for instance, didn't really get
> > solid until after 3Dfx shut its doors and released all their docs
> > on-line for free. When all the packages went modular, it was supposed
> > to
> > nudge the bigger distributors (RedHat, SuSE/Novell, Debian, etc...) to
> > maintain their own X.org-derived distributions of X.org software, and
> > perform stability testing on the feature snapshots and release their
> > own
> > distributions as development went on on the various freedesktop.org
> > projects. Basically, to take a more active role in testing and
> > reporting
> > X.org problems.
> 
> Nb: there's now an upstream xorg release manager (Adam Jackson), who
> also happens to be the X lead here at Red Hat.

That's great to hear. I haven't followed RH since FC3, so my comments
above about distro participation might be somewhat dated. I expect that
SuSE, who's leading the radeonhd work, also has some similar thing going
on.

X.org has been assembling "reference releases", but I have recently been
seeing the chatter about having a more active role from the X Consortium
in releases, to get the to happen more frequently.

> 
> > To this day, that hasn't happened except in the case of the OpenBSD
> > project. Now everyone suffers because graphics hardware is getting
> > close
> > to having a shorter lifespan than X.org releases. The X.org
> > consortium,
> > to its credit, has finally recognized this and recently announced it
> > is
> > going to change its release schedule to be more aggressive. The likely
> > result of this is a much quick time-to-market for new features, at the
> > expense of an increase in bugs exposed to the public (and hopefully,
> > found quicker and fixed quicker).
> > 
> > Today graphics hardware provides all sorts of features not considered
> > by
> > the developers when X.org 1.3 or 1.4 were released. The development
> > trees are where all this stuff is being developed (EXA, DRI2, next-gen
> > RandR code, new DRM). They've done a heck of a lot of overhaul in the
> > Mesa and Xserver source code trees in the past couple months. The best
> > I
> > can say is that, following the lists myself and the chats, they are
> > working really hard at getting this stuff together. You should
> > probably
> > see 1.5 released with a lot of this new feature-set around August. If
> > you want to improve the odds of this happening, you should get
> > involved.
> > 
> > I would, at the very least, recommend you try forwarding your email to
> > the developers list at X.org and also your Linux distribution. Both
> > are
> > culpable in the problems that you are experiencing.
> 
> My distribution of choice is already shipping a 1.5 pre-release with all
> these goodies. :)
> 
> Funnily enough though, Fedora 9 actually got a lot of flak for shipping
> with the 1.5 pre-release code, mostly since the binary nvidia driver was
> broken at release time... Overall though, its definitely been worth it,
> particularly the new randr stuff for my own usage.

Yeah, same here. I gave up on most binary-only distributions because of
their being tied to software that was way out of date, and many of the
maintainers' reluctance to forward-port more frequently. I'm actually
tracking on the 1.6 development branch (xorg-server master from fd.o
git), and it runs pretty well.

In all, my platform consists of:
  * FreeBSD 8.0-CURRENT, sources as of two nights ago, with some local
patches 
that I've got to have to get around the lack of a PCI MMIO remapper
in FreeBSD
and that the HP BIOS writers overlap my AHCI and HD-Audio MMIO
regions (yay!)
  * The latest masters from the git repository for the packages that I
listed 
earlier, from freedesktop.org
  * FireFox-3
  * All on amd64

Generally, with the exception of maybe once or twice every three months,
I have a perfectly stable reliable system, and can be sure that I can
safely update any number of those packages to get the latest features,
yet still keep stability. I submit requests weekly upstream to whatever
is giving me trouble, and it typically gets handled within about a week.
Those one or two times that I do get something that breaks my system, I
can recover from it given a couple of hours, back-track to an earlier
revision, and then proceed to keep working my day job (and then deal
with the thing that broke it all over the weekend).

For a completely free and 

Re: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Wed, 2008-07-02 at 09:12 -0400, Coleman Kane wrote:
> It is really important to understand, though, that the X.org project
> is
> really one without a "home" or "owner". The X Consortium (x.org)
> really
> only committed to provide some hosting, and maintain a central
> repository of protocol, format, and other project-related standards
> and
> specifications. Through its history as X.org and XFree86, it has never
> gotten significant support from the hardware vendors that it is
> expected
> to support. Support for 3Dfx hardware, for instance, didn't really get
> solid until after 3Dfx shut its doors and released all their docs
> on-line for free. When all the packages went modular, it was supposed
> to
> nudge the bigger distributors (RedHat, SuSE/Novell, Debian, etc...) to
> maintain their own X.org-derived distributions of X.org software, and
> perform stability testing on the feature snapshots and release their
> own
> distributions as development went on on the various freedesktop.org
> projects. Basically, to take a more active role in testing and
> reporting
> X.org problems.

Nb: there's now an upstream xorg release manager (Adam Jackson), who
also happens to be the X lead here at Red Hat.

> To this day, that hasn't happened except in the case of the OpenBSD
> project. Now everyone suffers because graphics hardware is getting
> close
> to having a shorter lifespan than X.org releases. The X.org
> consortium,
> to its credit, has finally recognized this and recently announced it
> is
> going to change its release schedule to be more aggressive. The likely
> result of this is a much quick time-to-market for new features, at the
> expense of an increase in bugs exposed to the public (and hopefully,
> found quicker and fixed quicker).
> 
> Today graphics hardware provides all sorts of features not considered
> by
> the developers when X.org 1.3 or 1.4 were released. The development
> trees are where all this stuff is being developed (EXA, DRI2, next-gen
> RandR code, new DRM). They've done a heck of a lot of overhaul in the
> Mesa and Xserver source code trees in the past couple months. The best
> I
> can say is that, following the lists myself and the chats, they are
> working really hard at getting this stuff together. You should
> probably
> see 1.5 released with a lot of this new feature-set around August. If
> you want to improve the odds of this happening, you should get
> involved.
> 
> I would, at the very least, recommend you try forwarding your email to
> the developers list at X.org and also your Linux distribution. Both
> are
> culpable in the problems that you are experiencing.

My distribution of choice is already shipping a 1.5 pre-release with all
these goodies. :)

Funnily enough though, Fedora 9 actually got a lot of flak for shipping
with the 1.5 pre-release code, mostly since the binary nvidia driver was
broken at release time... Overall though, its definitely been worth it,
particularly the new randr stuff for my own usage.


-- 
Jarod Wilson
[EMAIL PROTECTED]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-02 at 00:16 -0400, Arc Riley wrote:
> 
>  So I guess some are indeed considering "released 16 months
> ago" as
> "extremely out of date".
> 
> Yes, 16 months ago is extremely out of date.
> 
> If a new stable release of a popular package is not packaged within a
> week, there's a problem.  It's a massive chilling effect to free
> software development when a large number of users don't have access to
> recent versions. 
> 
> It hurts community support as well, people hit bugs that were fixed
> over a year ago and they can't easily upgrade because a newer version
> has not been packaged yet.  That's really bad.  Our ability to fix
> bugs and release a new version within a few days, getting it into
> people's hands so they can take advantage of the bugfix or new
> feature, gives us a huge advantage over proprietary software.
> 
> It is bleeding edge to grab a projects development tree from git or
> svn.  It's cutting edge to download a beta or release canidate.  A
> stable release should be packaged and available for upgrade.
> 
> I'm not talking about maintaining support for older versions, that's a
> separate issue entirely.  I'm talking about having newer stable
> versions packaged so that those who need them can get them without
> having to download, compile, and install on their own.
> 

A little known secret in the free software world is that the X.org
system (as a whole) really hasn't had a home since the fracture between
the XFree86 folks and the X Consortium members back in 2004 when XFree86
decided to change to a new GPL-incompatible license. This was, of
course, after a number of other snafus, one of which was the ejection of
Keith Packard from the core team (who had garnered a lot of respect in
the community), as well as the appearance to many of us outsiders that
the core had less and less time to focus on the project, but were highly
reluctant to offloading responsibilities to new members.

At that time, the X Consortium (x.org) picked up the pieces of the last
X11-licensed XFree86 4.4 pre-release and set into motion a series of
events that has resulted in the 100+ distributed projects that make up a
"functional" X deployment. The consortium offered to act as host to
release the "reference distribution" of future X servers, but IIRC they
only gave a temporary commitment back then (until freedesktop.org can
organize itself).

At some point during X11R6.8.0, it was determined that the whole
"cathedral model" of development just was not going to work, as the
project fell rapidly behind (even more so than it is now). They
committed to drop that model as of the 7.0.0 release (again, IIRC), and
distribute the project pieces out to whomever was willing to pick them
up to maintain them (or whomever had been actively maintaining the best
patch set).

Still, to this day, X.org remains stretched pretty far. They are
probably top on the list of projects that could stand to get some more
help (if all us Linux/UNIX geeks want to keep having a nice windowing
system). This isn't just the X system for a bunch of free OS's, but also
the one for Solaris, Mac OS X (not Aqua, but the actual X-server
implementation), and pretty much everyone else that uses X11 in some
manner. I don't even know if there are commercial X servers out there,
not using the X.org code-base, that are better.

It is easy to get upset that you might need to jump through hoops to get
your brand-spanking-new graphics card working under your Linux distro.
You happened to get the card during a transition period while the brand
new generation of X drivers for current and future ATI cards is under
development. This is the first time they (ATI/AMD) have undertaken such
a project, and it is moving along much quicker than the previous
X-driver developments that I've followed (tdfx, nv, ati r300). If you
help them design the driver (bug reports!), then you help them build a
foundation to more quickly get their future R700 and R800 GPUs supported
with.

If you can spare it, they can use the help: bite the bullet and run the
development stuff on your box, and give them reports. For the most part,
the card isn't going to "just work" easily if you're still on the old
releases of X.org, no matter when it is. If you want hardware to "just
work" then you've got to buy the stuff that came out a year ago, and has
had people using it already for a long time. One important part of the
whole FOSS experience has always been (for me, anyhow) participation. I
can either buy some proprietary software mess and be on their tech
support line answering dumb questions when it doesn't work, or I can go
in and try to act to fix it myself.

It is really important to understand, though, that the X.org project is
really one without a "home" or "owner". The X Consortium (x.org) really
only committed to provide some hosting, and maintain a central
repository of protocol, format, and other project-related standards and
specifications. Throug

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

>  So I guess some are indeed considering "released 16 months ago" as
> "extremely out of date".


Yes, 16 months ago is extremely out of date.

If a new stable release of a popular package is not packaged within a week,
there's a problem.  It's a massive chilling effect to free software
development when a large number of users don't have access to recent
versions.

It hurts community support as well, people hit bugs that were fixed over a
year ago and they can't easily upgrade because a newer version has not been
packaged yet.  That's really bad.  Our ability to fix bugs and release a new
version within a few days, getting it into people's hands so they can take
advantage of the bugfix or new feature, gives us a huge advantage over
proprietary software.

It is bleeding edge to grab a projects development tree from git or svn.
It's cutting edge to download a beta or release canidate.  A stable release
should be packaged and available for upgrade.

I'm not talking about maintaining support for older versions, that's a
separate issue entirely.  I'm talking about having newer stable versions
packaged so that those who need them can get them without having to
download, compile, and install on their own.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Tue, 2008-07-01 at 21:26 -0400, Bruce Labitt wrote:
> Jarod Wilson wrote:
> > On Tue, 2008-07-01 at 18:47 -0400, David W. Aquilina wrote:
> >   
> >> On Tue, Jul 01, 2008 at 05:19:24PM -0400, Labitt, Bruce wrote:
> >> 
> >>> I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
> >>> onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.
> >>>   
> >> I'm not sure how closely SL follows CentOS/RHEL, but RHEL 5.2 introduced
> >> the 'radeon_tp' driver ("tech preview") with experimental support for
> >> the R500/R600-based cards.
> >> 
> >
> > SL follows pretty closely for the base packages, would be surprised if
> > SL5.2 didn't also have that driver.
> >
> >   
> As I understand SL5.2 just came out.  If one navigates their server I 
> can find 5.2, but there are no direct links to the download.
> 
> I'll check the 5.2 area for radeon_tp
> 
> Can I presume that a 5.1 to 5.2 "upgrade" is not too painful?

Yes. 5.x to 5.x+1 upgrades are heavily heavily heavily tested before the
x+1 update release. Rarely ever is there much more than a bug fix to any
core packages, and only things on the periphery (i.e., not build-time or
run-time deps of a bunch of other stuff) get any significant
version-bumps (such as firefox 3 being in 5.2 vs. ff2 in 5.1 and
earlier). The only time you might run into issues is if you've got a
significant amount of packages installed from a 3rd-party repo that
plays fast and loose...

-- 
Jarod Wilson
[EMAIL PROTECTED]


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Ben Scott]

On Tue, Jul 1, 2008 at 10:17 PM, Arc Riley <[EMAIL PROTECTED]> wrote:
> Or use Gentoo, one of the few distros that's reasonable in keeping up to
> date.

  So I guess some are indeed considering "released 16 months ago" as
"extremely out of date".

  Per chance, I was just reading today about how SGI is promising to
support IRIX 6.5, released in 1998, though 2013.  Red Hat Enterprise
Linux 2.1, released in 2002, will be supported through 2009.  And I
myself am irritated that at work, I'm going to need to retire our
Windows 2000 systems when Microsoft EOL's them in 2010.

  I think you and I walk in different worlds.  :)

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

> Beware, it is not for the faint of heart. You will probably have to
> suffer through many hurdles like any good beta tester, if you want the
> goods.


Or use Gentoo, one of the few distros that's reasonable in keeping up to
date.

emerge -av xf86-video-radeonhd

Of all the systems I have, running Fedora, Suse, Ubuntu, Debian, etc, the
Gentoo systems are the easiest to maintain.  Some distros (ie, RPM-based)
you need to wait a year or more to use a recent release, and yea often you
need to upgrade your whole OS just to get a new version of something.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Tue, 2008-07-01 at 18:41 -0400, Ben Scott wrote:
> On Tue, Jul 1, 2008 at 6:30 PM, Labitt, Bruce
> <[EMAIL PROTECTED]> wrote:
> > In any case, first I'd like to take a look at finding more current xorg.
> 
>   If you try and replace the X-related packages provided by the
> distro, you'll probably end up having to rebuild practically every
> X-based package on the system.  They will all depend on the X
> libraries.  You'd basically be recompiling the entire distro (minus
> stuff that doesn't use X).

If you are starting from X.org 1.4, this isn't so much the case anymore.
You can update many of the packages independently with one another,
taking care to simply make sure you get the upstream dependencies that
are affected. For the most part, packages such as Mesa and libX11 have
been developed to maintain a relatively rigid API, resulting in that
they can be upgraded without too much breakage from apps.

> 
>   So if you want to have a go at upgrading X, I would suggest doing a
> parallel install of the X server into a different directory (e.g.
> /usr/X11R7.4/ or /usr/local/X11/ or something like that).  You should,
> in theory, be able to run a newer X server, while having all the X
> clients use the libraries shipped with the distribution.  The X
> protocol is known for being fairly backwards compatible.
> 
>   That might get messy for DRI (accelerated 3D) stuff, though.  I have
> no idea how DRI works internally, but the "Direct Rendering" part of
> the name would seem to suggest version differences might matter more.
> :)
> 
> > xorg is not particularly simple to figure out what to do.
> 
>   I've never had to build X, but from what I've been told, it's one of
> the more challenging things to do.

In the monolithic days, it was a terrible mess. It has gotten easier as
they've modularized the codebase. Still, there are many packages and no
straight-forward answer of what to do with them.

> 
> -- Ben

This is one of those cases where source-based distributions rule (and
the main reason I use them exclusively).

I was successfully able to get the new xf86-video-radeonhd (R500/R600
X.org driver) working well by updating the following packages from
freedesktop.org git repositories:
  * dri2proto
  * mesa/drm
  * git
  * glproto
  * inputproto
  * kbproto
  * libX11
  * libXdamage
  * libxcb
  * mesa/mesa
  * xorg-server
  * xf86-input-keyboard
  * xf86-input-mouse
  * xf86driproto
  * xextproto
  * randrproto
  * x11proto
  * libXext
  * libXi
  * libXrandr
  * libpciaccess
  * libxkbfile
  * libxkbui
The rest of my x.org packages are the ones I built from the 1.4
releases, which are in FreeBSD's ports collection. You should be able to
use either the latest xf86-video-radeonhd or xf86-video-ati to get DRI,
AIGLX, EXA, Compositing, and other niceties. I hear the R5xx cards are
easier to support than my RS690.

Beware, it is not for the faint of heart. You will probably have to
suffer through many hurdles like any good beta tester, if you want the
goods. The good news is that it will pay off in the end. I've be
corresponding closely with the guys who've been doing a lot of the
FreeBSD work, and passing my patches and bug reports along. They've been
a very prompt and responsive bunch.

If you go down this path, I recommend getting on *both* the
xf86-video-ati and xf86-video-radeonhd mailing lists (visit
http://www.radeonhd.org/). Additionally, both teams manage IRC channels
on Freenode, where there is nightly activity going on, and you can
usually get interactive help that way.

A good place to get started:
  * http://www.x.org/wiki/radeonhd
  * http://www.x.org/wiki/radeon (less helpful)

-- 
Coleman Kane

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Bruce Labitt]

Jarod Wilson wrote:
> On Tue, 2008-07-01 at 18:47 -0400, David W. Aquilina wrote:
>   
>> On Tue, Jul 01, 2008 at 05:19:24PM -0400, Labitt, Bruce wrote:
>> 
>>> I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
>>> onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.
>>>   
>> I'm not sure how closely SL follows CentOS/RHEL, but RHEL 5.2 introduced
>> the 'radeon_tp' driver ("tech preview") with experimental support for
>> the R500/R600-based cards.
>> 
>
> SL follows pretty closely for the base packages, would be surprised if
> SL5.2 didn't also have that driver.
>
>   
As I understand SL5.2 just came out.  If one navigates their server I 
can find 5.2, but there are no direct links to the download.

I'll check the 5.2 area for radeon_tp

Can I presume that a 5.1 to 5.2 "upgrade" is not too painful? 

Bruce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Jarod Wilson]

On Tue, 2008-07-01 at 18:47 -0400, David W. Aquilina wrote:
> On Tue, Jul 01, 2008 at 05:19:24PM -0400, Labitt, Bruce wrote:
> > I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
> > onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.
> 
> I'm not sure how closely SL follows CentOS/RHEL, but RHEL 5.2 introduced
> the 'radeon_tp' driver ("tech preview") with experimental support for
> the R500/R600-based cards.

SL follows pretty closely for the base packages, would be surprised if
SL5.2 didn't also have that driver.

-- 
Jarod Wilson
[EMAIL PROTECTED]


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[David W. Aquilina]

On Tue, Jul 01, 2008 at 05:19:24PM -0400, Labitt, Bruce wrote:
> I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
> onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.

I'm not sure how closely SL follows CentOS/RHEL, but RHEL 5.2 introduced
the 'radeon_tp' driver ("tech preview") with experimental support for
the R500/R600-based cards. 

-David

-- 
David W. Aquilina
[EMAIL PROTECTED]
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Ben Scott]

On Tue, Jul 1, 2008 at 6:30 PM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:
> In any case, first I'd like to take a look at finding more current xorg.

  If you try and replace the X-related packages provided by the
distro, you'll probably end up having to rebuild practically every
X-based package on the system.  They will all depend on the X
libraries.  You'd basically be recompiling the entire distro (minus
stuff that doesn't use X).

  So if you want to have a go at upgrading X, I would suggest doing a
parallel install of the X server into a different directory (e.g.
/usr/X11R7.4/ or /usr/local/X11/ or something like that).  You should,
in theory, be able to run a newer X server, while having all the X
clients use the libraries shipped with the distribution.  The X
protocol is known for being fairly backwards compatible.

  That might get messy for DRI (accelerated 3D) stuff, though.  I have
no idea how DRI works internally, but the "Direct Rendering" part of
the name would seem to suggest version differences might matter more.
:)

> xorg is not particularly simple to figure out what to do.

  I've never had to build X, but from what I've been told, it's one of
the more challenging things to do.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Ben Scott]

On Tue, Jul 1, 2008 at 5:49 PM, Arc Riley <[EMAIL PROTECTED]> wrote:
> I can't advise on how to go about upgrading since I'm completely unfamiliar
> with "Scientific Linux" ...

  From what I'm told, Scientific Linux is basically CentOS plus custom
packages and some tweaks.  And CentOS, of course, is basically Red Hat
Enterprise Linux minus some trademarked material.  According to
Wikipedia, CentOS/RHEL 5 was released in March 2007.  Is that really
considered "extremely out of date" now?  Yikes.

  One of RHEL's goals is version stability over time, so it's unlikely
major changes to the X server are going to appear in it.  If the
driver changes are self-contained enough, the new driver might get
backported.  But if everything else really does need updating, too, it
sounds like the driver needs a lot of supporting infrastructure
changes, so that's unlikely, too.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

RE: General Procedure to get ATI/DRI card running?

[Labitt, Bruce]

 



From: Arc Riley [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 01, 2008 5:49 PM
To: Labitt, Bruce
Cc: gnhlug-discuss@mail.gnhlug.org
Subject: Re: General Procedure to get ATI/DRI card running?

 

Thats an r500 based card, so older Xorg versions don't support even 2d
on it.  Keep in mind r500/r600 support (even 2D) is new as of only a few
months ago, since AMD released the specs, so you'll need to upgrade
quite a few packages including xorg server, xlib, and Mesa.

I can't advise on how to go about upgrading since I'm completely
unfamiliar with "Scientific Linux" but based on your xorg server version
I'm willing to bet the rest of your packages are extremely out of date.
You may want to consider (yea I realize it's a pain) migrating to a
different distro, it may be more work to manually compile/install the
upgraded Xorg than it'd be to install a whole new system.

After that, you'll want to install the "radeonhd" driver being developed
by AMD and Novell.  It's free software and has decent support for the
r500 series.  Instructions and more details:

http://www.x.org/wiki/radeonhd

The standard "radeon" driver in more recent Xorg/dri versions supports
2D on r500/r600 so once you get that updated you'll at least be able to
use a GUI to go through the above steps.



On Tue, Jul 1, 2008 at 5:19 PM, Labitt, Bruce
<[EMAIL PROTECTED]> wrote:

I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.

So I just plugged the Radeon in and started the computer.  Um, during
boot it said - "Oh no, you don't want to do that... You've got too many
video sources for your monitor... Unplug one and start over."  So I did.
Everything was fine until the OS tried to start X.  Then everything
died.  I got a couple of options to look at.  An error message came up
and said it could not find a video card.  Of course, I don't know how I
could have read anything on the screen, if it did not find the card, but
I digress.  It said I could fix things if I were root, so I dutifully
complied.  As soon as I became root it tried and failed to start x.  It
then said, "hey, I'm brilliant, why don't I probe stuff and generate a
new x.conf file?"  The screen turned pretty colors for a while and
eventually froze.  After a while, (many minutes) I reset the computer.

So I currently have xorg-x11-server 1.1-48.41.el5-2.1

What do I need to do to 1) get X to even start. 2) run 2D 3) run 3D.
The computer is back to running on the intel chipset for now.

Do I need to update the above file?  There does not appear to be an
update in the repository.  I don't mind compiling stuff, having compiled
octave, lapack, blas, and a few other packages.  However, having not
done this adventure before (os video) I don't know what the order of
steps should be.

There was nothing on the SL site on video upgrades, although they did
have proprietary drivers with no instructions on how to install.

I'd like to go with OS / DRI if at all possible.

Without belaboring this further, a couple of steps, or a general
procedure would be greatly appreciated.

Thanks,
-Bruce

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[Labitt, Bruce] 

 

Thanks Arc.  Scientific Linux is based on RHEL 5.1.  At this point I
have a bit invested in the distro, too much stuff compiled for it.  It
is somewhat recent - about as recent as RH 5.1.  No it isn't like FC9,
but the support for it is longer too.  In any case, first I'd like to
take a look at finding more current xorg.  

 

xorg is not particularly simple to figure out what to do.  They point
you to a directory full of directories.  No giant tarball, just a
million little ones.  I found a link to downloading cvs of xorg.
Slightly scary.  I'll look at it some more tomorrow and decide what to
do.

 

Regards,

Bruce

 

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: General Procedure to get ATI/DRI card running?

[Arc Riley]

Thats an r500 based card, so older Xorg versions don't support even 2d on
it.  Keep in mind r500/r600 support (even 2D) is new as of only a few months
ago, since AMD released the specs, so you'll need to upgrade quite a few
packages including xorg server, xlib, and Mesa.

I can't advise on how to go about upgrading since I'm completely unfamiliar
with "Scientific Linux" but based on your xorg server version I'm willing to
bet the rest of your packages are extremely out of date.  You may want to
consider (yea I realize it's a pain) migrating to a different distro, it may
be more work to manually compile/install the upgraded Xorg than it'd be to
install a whole new system.

After that, you'll want to install the "radeonhd" driver being developed by
AMD and Novell.  It's free software and has decent support for the r500
series.  Instructions and more details:

http://www.x.org/wiki/radeonhd

The standard "radeon" driver in more recent Xorg/dri versions supports 2D on
r500/r600 so once you get that updated you'll at least be able to use a GUI
to go through the above steps.


On Tue, Jul 1, 2008 at 5:19 PM, Labitt, Bruce <[EMAIL PROTECTED]>
wrote:

> I just got an ATI/AMD Radeon X1650 Pro video card to try to replace the
> onboard video on a Dell Optiplex 745 running Scientific Linux 5.1.
>
> So I just plugged the Radeon in and started the computer.  Um, during
> boot it said - "Oh no, you don't want to do that... You've got too many
> video sources for your monitor... Unplug one and start over."  So I did.
> Everything was fine until the OS tried to start X.  Then everything
> died.  I got a couple of options to look at.  An error message came up
> and said it could not find a video card.  Of course, I don't know how I
> could have read anything on the screen, if it did not find the card, but
> I digress.  It said I could fix things if I were root, so I dutifully
> complied.  As soon as I became root it tried and failed to start x.  It
> then said, "hey, I'm brilliant, why don't I probe stuff and generate a
> new x.conf file?"  The screen turned pretty colors for a while and
> eventually froze.  After a while, (many minutes) I reset the computer.
>
> So I currently have xorg-x11-server 1.1-48.41.el5-2.1
>
> What do I need to do to 1) get X to even start. 2) run 2D 3) run 3D.
> The computer is back to running on the intel chipset for now.
>
> Do I need to update the above file?  There does not appear to be an
> update in the repository.  I don't mind compiling stuff, having compiled
> octave, lapack, blas, and a few other packages.  However, having not
> done this adventure before (os video) I don't know what the order of
> steps should be.
>
> There was nothing on the SL site on video upgrades, although they did
> have proprietary drivers with no instructions on how to install.
>
> I'd like to go with OS / DRI if at all possible.
>
> Without belaboring this further, a couple of steps, or a general
> procedure would be greatly appreciated.
>
> Thanks,
> -Bruce
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/