Jakub Piotr Cłapa
loc at toya.net.pl
Sun Jun 27 18:41:45 PDT 2004
Daniel Stone wrote:
> On Sun, Jun 27, 2004 at 10:35:06PM +0200, Jakub Piotr C?apa wrote:
>>Daniel Stone wrote:
>>>On Sun, Jun 27, 2004 at 10:18:43PM +0200, Jakub Piotr C??apa wrote:
>>>>Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
>>>Thanks for the catch. Maybe it's worth renaming r128/atimisc/radeon to
>>>ati-r128/ati-atimisc/ati-radeon or such, and then symlinking the old
>>>names for compatibility?
>>Maybe. Tha main problem is Xorg binary loading sth as a driver without
>>complaining about it not being a driver. :D It should be checked somehow
>>IMHO. A list of display drivers + compatibile hardware (better - PCI
>>ids) would also be cool. (or is it actually done in -configure? tt also
>>failed for me)
> Hm, interesting. I suppose we could error out if there's no relevant
> DriverRec in the module we explicitly requested. I think
> radeon/r128/whatever have an output DriverRec, tho.
IMHO we need something to distinguish module types. But don't ask me
what it should be... ;-) I'm not on this level of debrix hacking. :D
> That list would be really, really long, BTW. And I don't think there's
> any standard interface to get all the PCI IDs.
My /etc/pci.ids is only 256K and it contains lots more than graphic
cards (+ the names would not have to be duplicated and driver names are
shorter ;). Maybe it wouldn't be as long as you think?
>>>It's not turned off, it's just currently built as a module
>>>(libfbdevhw.la: lib_LTLIBRARIES = libfbdevhw.la, vs noinst_LIBRARIES =
>>>libfbdevhw.a, and linked into the final binary).
>>Don't understand the difference (yet) but AFAIR fbdev is complaining
>>about missing fbdevhw.
> Right. What happens is that you can't have module A depending on a
> *variable* in module B, only a function. So if module A needs a variable
> from module B, that just won't work - it has to be hidden behind a
> function. In this case, fbdev/nv need variables from fbdevhw and xaa, so
> fbdevhw and xaa can't be built as modules - they need to be built in to
> the binary.
> That's the executive summary.
Now I understand. What you have broken is modules like pcidata ;-)
(EE) Failed to load module "pcidata" (module does not exist, 0)
Fatal server error:
Unable to load required base modules, Exiting...
Make them modules again or stop forcing to load them.
>>>>Btw. My last e-mail ought to go to the list (and the previous one as
>>>>well). Are you sure Reply-to should be considered harmful? :D
>>>Pretty sure, yep. I use group reply by default.
>>So I have to change the way I'm used to use my e-mail program. (groups
>>I'm most active on set the Reply-To header) :D
> Ah, sorry. That was the way fd.o was set up, and the way I'm used to - I
> don't really want to change it, personally. ;)
Not a big deal, really. :D
While building in a clear enviroment I've catched some other problems
(patch is available ) (ordered as fixes appear in the diff)
1. compalloc.c - probably you forgot to commit it (it was commited into
xserver by mistake, then reverted); fixes building with
--enable-composite (haven't tried running because of the lack of
2. #include <X11/DECkeysym.h> - seems redundand to me and we don't have
this in debrix anywhere (it is in the Xorg tree - should be
3. hw/xorg/include/X11/extensions/*.h header file weren't installed
4. same as 2
5. we have X11/Xdmcp.h and pkgconfig --cflags xdcmp returns
/usr/X11R6/include, not /usr/X11R6/include/X11
Hope that helps.
Jakub Piotr Cłapa
More information about the xorg