CVS Update: xc (branch: trunk)

[Adam Jackson]

On Tuesday 18 October 2005 14:02, Alan Hourihane wrote:
> On Tue, 2005-10-18 at 13:48 -0400, Adam Jackson wrote:
> > On Tuesday 18 October 2005 04:34, Alan Hourihane wrote:
> > > On Mon, 2005-10-17 at 21:02 -0700, Aaron Plattner wrote:
> > > > Log message:
> > > >   * programs/Xserver/hw/xfree86/loader/Imakefile:
> > > >   * programs/Xserver/hw/xfree86/loader/misym.c:
> > > >   Export DamageDamageRegion.  Not bumping the ABI version since we
> > > > did that already for this release.
> > >
> > > Might be easier to just make miext/damage a loadable module rather than
> > > doing this.
> >
> > If you make it loadable, who loads it?
>
> The driver is always in charge.

So instead of the 6.8 situation, where Damage is enabled by default, we have 
to modify every driver to load the Damage module?  Damage, an extension with 
exactly zero hardware interaction?

The point I'm getting at here is that we currently have no way of loading 
extensions from the core by any other method than a Load line in xorg.conf.  
(Well, and the bitmap/scanpci situation, but those are broken for other 
reasons.)  If you want to make the Damage extension loadable, you have to add 
a way to get it loaded by default, _and_ to express the dependency order 
(Damage requires Fixes, Composite requires Render...).  The loader simply is 
not that smart yet, and fixing it would be way more work than one more line 
in misym.c.

The cheap hack is to require people to say Load "damage", and that's bogus, 
because any time you require people to add a line to the config to make it Do 
What They Wanted In The First Place you've already lost.  Particularly when 
adding the requirement for that line breaks existing configs.

So while you may be right in the broader sense about extensions all being 
loadables, all that would do for Damage in the near term is make the user 
experience worse.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20051018/c316a483/attachment.pgp>