Best-card-for and practicality-of r600g on a Debian desktop?

[DanL]

I think it will be okay with testing/xorg 1.7.x
sid just moved to xserver 1.9.x not too long ago. You can probably use checkinstall or something even more proper if you want to build packages. I'm just lazy, so...

[DanL]

Can the environment variables needed for loading mesa from /usr/local or /opt be set for use with gdm?

I'm not really sure what you're referring to here. If it's any help, I use xfce/gdm. Oh, and since I haven't ranted about the one minute edit time limit recently, I would like to do so here (thank you).

[yotambien]

Using sid, you don't really have to compile anything. The repositories are very up-to-date. The only circumstance I can think of is a combination of two events: a) you absolutely can't wait for some particular development in the stack AND b) debian is in a 'frozen' stage (which happens for some long, tedious months before a stable release once every 2 years). And that's it. I don't think it's good advice telling people to install their drivers from source.

Having said this, I do compile drm, and the 2D and 3D drivers on a regular basis, mostly for recreational purposes.

The downside of using sid is that sooner or later something you upgraded will end up causing problems, which the user has to solve playing with the package manager--sometimes requiring some fiddling. I'd say this may happen 3 or 4 times a year. In any case, I haven't reinstalled linux since I installed Debian 4 years ago. In that time I run into problems I could not solve with the help of google once, and it was caused by quite an overlap of user and system screw-ups.

[whizse]

I'm not really sure what you're referring to here. If it's any help, I use xfce/gdm. Oh, and since I haven't ranted about the one minute edit time limit recently, I would like to do so here (thank you).

I guess he's referring to LIBGL_DRIVERS_PATH (and/or LD_LIBRARY_PATH for libGL). I don't see why you couldn't add them to gdm.

I personally prefer to do it the other way around, have the systems stable Mesa as a default and manually launch the stuff I want to run with Mesa from git from a terminal with the envvars set.

[utrrrongeeb]

I think it will be okay with testing/xorg 1.7.x

Can anyone else confirm this? [ie xf86-video-ati from git]

@DanL: I'm going to use GDM and Xfce as well. Wonder if Xfce 4.8 is in backports, or if it'll work from experimental....
Does Xfce's compositor work with r600g?

Using sid, you don't really have to compile anything. The repositories are very up-to-date.
...I don't think it's good advice telling people to install their drivers from source.
...
The downside of using sid is that sooner or later something you upgraded will end up causing problems...

True.
But I was going to use testing, hence the compilation. DanL makes it look easy enough.

I guess he's referring to LIBGL_DRIVERS_PATH (and/or LD_LIBRARY_PATH for libGL).

Correct.
I finally looked at #radeon and found the link to the proverbial manual, which answers those questions.

I personally prefer to do it the other way around, have the systems stable Mesa as a default and manually launch the stuff I want to run with Mesa from git from a terminal with the envvars set.

That sounds more difficult. Is the git Mesa less stable, or is that just a precaution?

[whizse]

That sounds more difficult. Is the git Mesa less stable, or is that just a precaution?

Well, there are occasional regressions, as in all software development.

Having the stable version as default is mostly a precaution I guess, but I would recommend it if you use a gl compositor or if the driver is at a development stage where GPU hangs can be expected.

[yotambien]

Well, there are occasional regressions, as in all software development.

Having the stable version as default is mostly a precaution I guess, but I would recommend it if you use a gl compositor or if the driver is at a development stage where GPU hangs can be expected.

The way I do it (somebody may cringe at this) is compiling and installing everything in the regular locations, i.e. I overwrite the distribution packages. I used to make backups of the regular libraries and drivers, but not anymore. If there is some problem that forces me to reboot, which happens rarely, I just reinstall the stuff from the repos.

But I was going to use testing, hence the compilation. DanL makes it look easy enough.

I'm not sure about using testing. There are situations where stuff is broken for longer than if running sid. In any case, another option you may want to consider is running testing with the unstable repository enabled, using pinning to avoid updating packages you don't want to update. This way you can fetch quite up-to-date drivers without compromising a lot (but I repeat, I'm not sure about how benefitial running testing is).

In case you don't know about pinning, here there is a tutorial of some sort (which I haven't read):

http://www.howtoforge.com/a-short-introduction-to-apt-pinning

[R15I23D05D14Y]

On the original post:

It sounds like you just want to use plain Debian Testing (ie, Wheezy). You probably won't have to compile anything, and testing breaks infrequently (although it is in the most unstable part of it's lifecycle at this moment). If you are used to stable, you can just stop updating when you have a good day .

If you build your system and testing isn't up-to-date enough, unstable should hold everything worth having. Use apt pinning and live in Wheezy, or move up to unstable.

On the state of testing

Wheezy is hopefully going to be up-to-date in the next month - mesa 7.10 and linux 2.6.38 are both staged in unstable. The libdrm update seems to be causing trouble #1, with luck the maintainers are only waiting for the kernel to be upgraded.

Gallium will be enabled once mesa 7.10 enters testing (as of Debian version 7.10-3 #2).

Don't use the Squeeze stack - the kernel is too old, I'm pretty sure power management was in 2.6.33. Debian Stable can run parts of the HIB, I expect everything you've listed would work on a 4XXX card (I'm basing my experiences off a 3450 in my machine).

There is a web page (#3) that tracks the versions of most of the key pieces of the puzzle, which might be of interest.

#1 http://bjorn.haxx.se/debian/testing.pl?package=mesa
#2 http://packages.debian.org/changelog...rent/changelog
#3 http://qa.debian.org/developer.php?l...sts.debian.org

[DanL]

@DanL: I'm going to use GDM and Xfce as well. Wonder if Xfce 4.8 is in backports, or if it'll work from experimental....
Does Xfce's compositor work with r600g?

Xfce 4.6.2 is still in the sid repo. Experimental now has 4.8.x packages, but I haven't felt the need to upgrade. I've been using the xfce compositor with r600g for a while (maybe 6 months?), and haven't had issues (YMMV).

[utrrrongeeb]

In any case, another option you may want to consider is running testing with the unstable repository enabled, using pinning to avoid updating packages you don't want to update.

If you build your system and testing isn't up-to-date enough, unstable should hold everything worth having. Use apt pinning and live in Wheezy, or move up to unstable.

Sounds like a good idea....

Wheezy is hopefully going to be up-to-date in the next month - mesa 7.10 and linux 2.6.38 are both staged in unstable. The libdrm update seems to be causing trouble #1, with luck the maintainers are only waiting for the kernel to be upgraded.

Gallium will be enabled once mesa 7.10 enters testing (as of Debian version 7.10-3 #2).

You're making a very good case for compiling mesa and libdrm.

I've been using the xfce compositor with r600g for a while (maybe 6 months?), and haven't had issues (YMMV).

Okay, that's good.


A neighbouring thread suggests problems with r600g in Wheezy, though.

By the way, I was hoping to run x86_64 -- are there any problems with that?