On Wed, 2008-11-19 at 16:55 +0000, Tom Horsley wrote: > > Speaking of falling back to vesa mode... > > At the risk of seeming radical, why not just always run anaconda with > xdriver=vesa by default? Since anaconda no longer generates any kind > of an xorg.conf file to "pollute" the install, why not just always use > the driver that always seems to work right? (Unless you are planning > some sort of 3D opengl installer enhancements soon :-). Three reasons. vesa doesn't always work. It will work even less often in the future, since Vista prohibits use of VBE services at runtime (removing some incentive for vendors to keep it working), and since EFI removes VBE altogether. And even for machines where it does do something, we're not really guaranteed that it will do what we're hoping for. I've seen BIOSes with no 800x600 mode, or with no 24bpp modes. Second, by Occam's Razor, we're trying to keep the install environment as similar to the runtime environment as we can. Otherwise you get bugs like "I have to install in text mode, but then gdm works fine", or worse, "graphical install worked but then gdm didn't show up". Depending on the reporter, one or the other might be below their pain threshold and thus not get reported, but if _both_ break, then we're sure we'll hear about it. (Or they'll just give up and run Windows, I suppose.) Third, and this is more of a petty code reason and a consequence of reason #2, xdriver= controls both the X driver anaconda uses _and_ the X driver it writes out to xorg.conf. If you say xdriver=radeon you'll get a config file that mentions radeon. The logic here is akin to the logic for kernel updates to preserve your /proc/cmdline when writing the new grub.conf. If you needed it to boot _this_ kernel, you'll probably need it to boot the next one; if you need xdriver= to make graphical install work, you'll probably need it to make runtime X work. #3 (and to some extend #2) we could change in the code, but I actually feel pretty strongly about the philosophical bits of #1 and #2. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
