[Xorg] debrix

[Jakub Piotr Cłapa]

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 ;-)
#v+
(EE) Failed to load module "pcidata" (module does not exist, 0)

Fatal server error:
Unable to load required base modules, Exiting...
#v-
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 [1]) (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
    modules ;)
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
    imported?)
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.

[1]http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-many_fixes.patch?rev=1.2

-- 
Regards,
Jakub Piotr Cłapa