© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Yeah, by the point he posted that set of logs the patch was already there which would force it to use nv because the pci id did exist even though it didn't work. The main problem is that we need to delete the xorg.conf entirely (and the pci ids) for xserver to use it's internally generated default driver priority system which would get around this issue. That has some problems in practice that I've run into where people have had framebuffer drivers by the kernel which can make the detections skip over some KMS drivers in favor of the fbdev ones.. Leaving the xorg.conf around and sticking to the pci.ids files is a horrible way to go about this because each driver handles it differently, and there are major problems with the way -nv in particular ends up having it done because a large portion of the supported cards do not get id's generated. One thing I noticed in this regard -- In the livecd-rootfs script a very old bug fix is included (that isn't relevant anymore per tjaalton) which deletes then touches an empty xorg.conf and even just having a blank one like that will screw up in this manner.
Line 477 here -
http://
One partial solution I can see would be to drop the xorg.conf completely at least on livecd's. Just dropping the xorg.conf would let xservers automatic configuration mechanism work which would let each brand of cards have their own priority table and the server will try to load each driver and then let the driver decide if its compatable or not before moving on to the next in the list. For instance on my intel graphics, it sets up a priority table of intel > i810 > vesa > fbdev and works its way down the list if the previous driver claims it doesn't support it. i810 should be removed probably as a side note, and we will have to make fbdev not try to claim it's the matching driver because of the small problem that kms has when its a module and there are framebuffer devices available packed into our initrds by the greedy initramfs-tools scripts. I have attached my /var/log/Xorg.0.log to show how it works when no xorg.conf exists, I didn't know it was this smart either :)
I think it would be possible for instance for ubuntu to carry a patch against hw/xfree86/
http://
Also notice they specifically force all nvidia cards in the 084x and 086x series (of which the 9100M G in this bug report belongs to) to use vesa because it is unsupported by anything else?
Anyway, these are just my thoughts on it after discussing it with people who understand how it works alot more than I do. I hope we can get it worked out so it's a painless release :)