On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > wrote: > > On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > > > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > > > the DDX select between them based on kms support and an xorg.conf > > > > setting (default to r300g, as that's the default upstream, and whichever > > > > r600 driver ends up being default in 7.10). This is not going to be > > > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > > > UMS support for radeon while defaulting to the upstream-default driver. > > > > > > IMHO any solution which doesn't allow easily choosing between the 3D > > > drivers during the X server's runtime (when KMS is enabled) isn't > > > adequate. > > > > Certainly not adequate for driver development, > > Actually, driver developers probably tend to have their own custom > setups anyway. > > > but is it necessary for end-users? This would be necessary for > > allowing per-application overrides, but should we care about this? > > Probably not as long as the default 3D driver works (well enough), but > e.g. for comparing between the 3D drivers it would be much more > convenient and save nerves and time, also for bug triagers. > > > > Can you see an easy solution which allows changes during X's runtime and > > will handle UMS transparently? > > One possibility would be an r[36]00_dri.so wrapper which can pass > through to the classic or Gallium drivers based on KMS vs. UMS and > configuration via environment variables and/or configuration files. This > might be appropriate for upstream as well. > That sounds an awful lot like work :). Also, my understanding was that UMS / classic mesa would not be particularly supported upstream. If you'd welcome such a patch, maybe that work is justified. I was only expecting to carry this dual-stack UMS/KMS hack for one release, maybe two, and then not caring at all about UMS after that. > However, given that switching to UMS will require some kind of tweaking > anyway, I'm not sure why the script / procedure for that couldn't just > include appropriate update-alternatives calls. > The trick is getting all the users to see the same documentation :).
Attachment:
signature.asc
Description: This is a digitally signed message part