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.