[cc: Dan, because he is one of Xorg developers. Task: verify what I say
here, and, if necessary, correct me.]
Jeremy Huntwork wrote:
> Alexander E. Patrakov wrote:
>> If my old notes still hold true, Xorg upgrade broke the driver
>> autoconfiguration from udev rules. We should either drop it (and have
>> the same bugs as upstream, i.e., using the "ati" driver for new (even
>> totally unsupported) cards made by ATI (unless this got fixed
>> upstream).
>
> I wouldn't mind a little more detail on this one, please.
OK, first some history. The first attempt to autodetect the user's video
card was to use xorg.conf with no explicit video driver. Then this code
(still in xorg-server-1.5.3/hw/xfree86/common/xf86AutoConfig.c) would run:
static const char *
videoPtrToDriverName(struct pci_device *dev)
{
/*
* things not handled yet:
* cyrix/nsc. should be merged into geode anyway.
* xgi.
*/
switch (dev->vendor_id)
{
case 0x1022:
if (dev->device_id == 0x2081)
return "geode";
else
return NULL;
case 0x1142: return "apm";
case 0xedd8: return "ark";
case 0x1a03: return "ast";
case 0x1002: return "ati";
<snip>
default: break;
}
return NULL;
}
The obvious problem: suppose that ATI releases a new card, totally
incompatible with all previous ones (and this did happen). Then, as they
are ATI, they will use the vendor ID 0x1002 and some new product ID.
Then, the code will return "ati" as the autodetected driver, but the
"ati" driver will not be able to talk to the card. End result: numerous
support requests, because Knoppix does a better job. So we must avoid
running this code at all costs.
Another solution is in the book: Xorg -configure. However, this is also
unusable for LiveCD purposes, as this destroys the text console on
VMware virtual video cards, and users rightfully complain about this
fixable problem:
http://www.linuxfromscratch.org/pipermail/lfs-support/2004-December/025180.html
So, what I did was to extract the supported PCI IDs from all video
drivers and to convert the resulting list into udev rules that edit the
pre-generated xorg.conf. See the resulting beyond-BLFS package at
http://wiki.linuxfromscratch.org/livecd/browser/trunk/packages/xorg-udev-rules/
However, after Xorg-7.2, the result became a blank list, because dlopen
fails (temporary fix: add dummy xf86DPMSSet() and xf86SaveScreen()
implementations). Anyway, the Probe function is NULL for all
pciaccess-enabled drivers. It is needed to use the lists added to the
drivers during this rework, available through the supported_devices
field of the DriverRec structure that the program already knows how to get.
Anyway, the ugly code at the beginning of this mail will no longer
matter in the future, as the symbol-based autoloader will replace it.
See the following patches (why aren't they in git yet?):
http://lists.freedesktop.org/archives/xorg/2008-January/032214.html
Then, there will be no errors on new ATI cards, and the need for my hack
will disappear.
>> If we stick to "only fonts listed in the book", then we essentially
>> require the book to copy the whole Unicode Font Guide, which is bad.
>>
>> If we accept Thai fonts, then, well, we accept a package not in the book.
>
> Ok. I don't mind adding it in again then. This is one of those areas
> that I interpret as BLFS 'allowing' for this piece, since it references
> it and provides a link. Of course, it could be argued that any open
> source software that can be built on Linux is 'allowed' by the LFS or
> BLFS framework, but that's not quite what I mean either.
>
> Here's a little bit more about how I specifically envision the policy:
>
> 1. Software provided in LFS cannot be skipped or excluded unless LFS
> says that it is optional, nor can the order be adjusted. The software
> must be built using the parameters and build options documented in LFS
> except for where such are labeled as optional (e.g., tests, package
> documentation)
OK.
> 2. Any software that falls outside of LFS can be included if:
> * instructions for it is contained in BLFS
> * BLFS references it as a possible piece of software for inclusion (a
> link to the software's home page)
OK if interpreted with "and" between the bullets, as BLFS provides
generic instructions for installing fonts. It would be even better if
BLFS provided generic instructions for testing font installation (i.e.,
mentioned fc-list for XFT and xlsfonts the for core font protocol).
> 3. Software that is part of BLFS and for which BLFS has build
> instructions must be built according to BLFS instructions verbatim
> except where the parameters or commands are noted as being optional.
> Extraneous patches or command parameters/configure switches are not
> allowed, unless they are declared as options in the BLFS page.
Is the following rewording for CMMI packages correct? "The ./configure
line should be composed from items contained either in the gray box or
in the Command Explanations section".
Not sure if this is just a workaround for Randy's policy of not
including ./configure arguments in the ./configure line in the grey box
if they need optional packages.
> The point of the policy is to provide a living example of a system built
> closely to LFS and BLFS specifications. It also serves to demonstrate
> and pinpoint flaws in either book, so it should be a good springboard
> for pushing new functionality into both books.
OK.
>>> * lftp
>> OK, although I will file a bug into BLFS.
http://wiki.linuxfromscratch.org/blfs/ticket/2678
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
