[arch-dev-public] Xorg changes / DRM modules

[Andreas Radke]

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.