Re: Ubuntu plans for Natty release
On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers
wrote:
> 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.
Is that an issue, given choosing the 3D driver is only possible with KMS
and will be useful for as long as there's more than one 3D driver?
If you feel it's too much work, how about trying the simple
update-alternatives solution first and worrying about something more
sophisticated if that turns out to be problematic?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
Reply to: