[Xorg] Notes from release call
daniel at freedesktop.org
Fri Jul 9 20:02:11 PDT 2004
On Fri, Jul 09, 2004 at 10:58:19PM -0400, Adam Jackson wrote:
> On Friday 09 July 2004 22:00, Daniel Stone wrote:
> > On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
> > > - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> > > on autotooling the x server but have found sticky issues with modules
> > > involving references to global symbols. They've been fixed in that
> > > tree, mostly, but this may prove to be a hazard for vendors moving to
> > > .so modules
> > Global symbols are OK, but they *must* be resolved at load time; they
> > cannot be lazily resolved. This means that the ATI driver, where ati had
> > global symbol deps on atimisc/r128/radeon, while the reverse was also
> > true, could not be loaded. Ever.
> > Right now, our compromise is that Load "ati" works, but
> > atimisc/r128/radeon doesn't. The current thinking (well, for me anyway),
> > is to make a fake libatimisc/libr128/libradeon which just depends on
> > libati, and then rename the real ones to libati_atimisc, or whatever.
> Not to be contrary, but I'd thought I'd resolved that (ie, that you could load
> r128 on its own without ati first). If not, perhaps everything except the
> chipset detection could be factored out into, say, aticore, which would then
> be loaded by atimisc/r128/radeon. 'ati' would then be shorthand for "I'm too
> lazy to figure out which chip I have, please load the right one for me".
> Alternatively, if there exists a loader call that can query if a module is
> already loaded, we can stick that at the beginning of the atimisc/r128/radeon
> init routines.
> Any of the above works for me, but I think I like the aticore approach best if
> it's feasible.
Oh, OK. I was just going on that we hadn't fixed that yet. My bad.
Nothing to see here. Move along, please. :)
Daniel Stone <daniel at freedesktop.org>
freedesktop.org: powering your desktop http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg