On Wed, Dec 3, 2008 at 11:06 PM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> [cc: Dan, because he is one of Xorg developers. Task: verify what I say
> here, and, if necessary, correct me.]
Well, that's a bit of a stretch. Really, I just sent a couple patches
and happened to dig through one of the uglier parts of the server.
> 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.
That's a really tough situation to deal with, and I don't think I'm
gonna have any great suggestions for handling it. Personally, I would
just let Xorg autoconfigure everything but have command line args for
the livecd that allow you to override the devce when this doesn't
work. But you've probably already tried this and it didn't work well
enough.
Here's something that might be interesting to you.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e368cf5
When you run `Xorg -modalias', you get output that looks like this:
alias pci:v00008086d000029D2sv*sd*bc*sc*i* intel
alias pci:v00008086d00002A42sv*sd*bc*sc*i* intel
alias pci:v00008086d00002E02sv*sd*bc*sc*i* intel
...
alias pci:v*d*sv*sd*bc03sc00i00* vesa
That might be a little tough to parse, but possibly it could help. You
could see if the card matches any any of the PCI IDs and throw a vesa
section in xorg.conf if it's not.
What does knoppix do? What does debian do? What does anaconda (fedora)
do? Maybe you can try this (as long as you have python):
https://fedoraproject.org/wiki/Rhpxl
> 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.
That looks like a good solution. I have no idea why that wouldn't be
applied. I would test it and ping the list.
Sorry I don't have any better suggestions.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
