Appending here two mails from an upstream dev(Dave Airlie). I'll talk to Jan how do deal with this in the near future. -Andy

We want to ship packages with all new features wherever possible. But we have to make sure, that at least 2D is always working and 3D should be stable and fast. We know we will often run into bugs first but our community likes it - see us as a big testing group for you :)

Unless you have a large amount of time of ppl with experience of graphics I'd recommned the following (below)..

That's why we ask for your recommendations what is already usable and worth packing.

1) kernel drm modules: Is it enough to ship the latest stable kernel? Or do you recommend drm-next or any other branch replacing the the default kernel modules in /lib/modules/${_kernver}/updates/ ? We are thinking about such additional packages we can update more often if needed (we did so in the past for nouveau-drm). Do you recommend to enable kms now by default for all chips?

Ship Linus kernel, when things leave staging, you can generally turn them on, not before unless you can provide the support to users and upstream feedback cycles for bugs. Its worse for us when ppl have a load of binary packages that the distro has just picked in the middle of a dev cycle and never upgrade. We generally provide experimental features so we can get feedback and debug them, shipping these without a supporting person in the distro keeping the feedback cycle alive is actually a drain on our end. We get bug reports for sutff 2-3 mths after we've fixed it because of some distros.

2) libdrm What configuration is recommended? Is enable eperimental api code needed and recommended for for certain chips?

Same, leave it alone, --enable-udev is probably all oyu want.

3) mesa Do you still recommend 7.6.1? When will it make sense to package 7.7? When Xorg 1.8 is out or when will the driver make use of 7.7 features?

7.7 is out, probably best to ship it now. since it contains all 7.6.1 fixes

4) Driver packages should be announced clearly on what they depend. Maybe better or more clear branching is needed.

Generally if there is experimental APIs then you need to do the research with normal packages on a Linux distro, the latest released everything should be the best option. Dave.

Shipping only stable releases and not staging stuff is less work for us but would leave people with new Ati cards in the dark.

All ATI cards shipping so have fine 2D support with the latest kernel + latest stable ATI driver (apart from displayport), if we had stable 3D of the quality you wanted it would have shipped.

Right now Radeon is the bad player. DRI1 isn't maintained for a long time. My X200m driven notebook never worked well with old hardware accelerated mode (freezes at login). DRI2 rewrite/KMS made it work well in Kernel .31 series and new libdrm with experimental ati api. It also worked stable but slow for most modern Ati cards. Kernel .32 series now speeds up stuff but gives freezes and lookups through all chipset families. We just reverted to old api in our stable repositories. But we want to fix it in our testing repositories.

DRI1 is still maintained and although we won't be adding new features to it, we still provide bug fixes, a bug fix for the x200m just went into the stable ATI branch this week for DRI1/UMS systems. So you are the perfect example of the problem we face with distros shipping KMS with no feedback loop, you say your x200m (this chipset is the worst in existance, not even AMD know how it works, so I expect it'll never be stable), regressed between .31 and .32, I'm not sure if we have a bug report of a git bisection to figure out which patch causes this so we can revert it. We haven't added many new features to the DRI2 kernel at all for rs480 so if it worked under .31 it most likely was something small in .32.

What's the best way to go? Report it to upstream and wait for rare fixes in Linus' kernels or provide full drm replacements from drm/radeon-next branch? We could react much faster and give more feedback that way.

Stay with Linus tree unless you can follow lists and guide users, adding new features that aren't stable means you face the problems you are seeing, and thus require the manpower to help with t hem.

releases to get branched code with a small announcement saying "hey, this shot now supports new features introduced by libdrm/mesa/Xorg/whatever..."

When KMS is out of staging we will be doing normal stuff, so far we don't recommend KMS to distros and we haven't shipped a libdrm or DDX with KMS enabled so we have no branch on which to do those sort of things. Dave.

Am Wed, 23 Dec 2009 09:40:04 +0100 schrieb Jan de Groot <jan@jgc.homeip.net>:

Looking at the mails, I think we should take these steps: - update to mesa 7.6.1 for now, you already did this.

- disable KMS for ATI by default, enable for Intel by default, as UMS is wrecked out their soon to release driver.

We will test if this is possible in our next kernel pkg.

- Package stable linux kernel, don't touch drm too much, just apply patches for known broken things, like the intel powermanagement bug that locks up the GPU.

I'm fine with this for core/extra repos.

- Package released drivers, or use git snapshots from the stable branch. For ATI, there's some maintenance work done on the 6.12-branch in git, I think it's wise to apply those.

I will have a look what it's worth applying or if a new release is planned from upstream. Just also removed the git based pkg from testing.

- for libdrm, package without extra flags, though you *might* want to enable libdrm-nouveau there to get the nouveau driver working. As always, stick with released libdrm, don't use git snapshots. Only provide nouveau drivers if you actually intend to use and update them.

Sure. Only stable libdrm releases because all driver heavily depend on its api. Ati api is back to stable state. For nouveau we need experimental api to get working 2D drivers.

After these switches, we should focus on getting mesa 7.7 in our distribution. Mesa 7.6.x is a dead end and upstream only supports 7.7 now.

No problem. It built fine here on top of the rolled back extra stuff. I'll put new packages into testing. I guess we need to rebuild all related ddx driver packages. Anything else will require rebuilds? The server? The sad part is that we leave all people with modern Ati cards in the dark until upstream declares their code as stable. This will make them going back to software rasterizer and either force them to use the closed source driver or use weird self made git packages from AUR. Because I'm also affected with my weird X200m card I'm still looking for a good solution how to offer a good set of binary packages people can use to try modern code. I could do this on my own like all other people from AUR but we could also setup an additional unstable repo at Gerolde. I could do this also in my public dir. I'd prefer to have people using one set of codebase for reporting bugs upstream. What do you think? -Andy

On Wed, 2009-12-23 at 11:21 +0100, Andreas Radke wrote:

No problem. It built fine here on top of the rolled back extra stuff. I'll put new packages into testing. I guess we need to rebuild all related ddx driver packages. Anything else will require rebuilds? The server?

Xorg-server might need a rebuild because it is tied to the GL API stuff. The drivers don't matter that much.

The sad part is that we leave all people with modern Ati cards in the dark until upstream declares their code as stable. This will make them going back to software rasterizer and either force them to use the closed source driver or use weird self made git packages from AUR.

That's where users come in. I think it's better to have a -git driver from AUR that is maintained, than a git snapshot in testing or extra which isn't updated very often because it works on your X200m. You can see this with intel also, where some users made an xf86-video-intel-newest package.

Because I'm also affected with my weird X200m card I'm still looking for a good solution how to offer a good set of binary packages people can use to try modern code. I could do this on my own like all other people from AUR but we could also setup an additional unstable repo at Gerolde. I could do this also in my public dir. I'd prefer to have people using one set of codebase for reporting bugs upstream. What do you think?

If you intend to maintain those drivers with regular updates, you're free to do so. The issue with radeon is that it's not only the drivers, but also kernel, mesa and libdrm.