On 9/12/2011 9:01 PM, Larry Finger wrote:
Although the KMS video drivers have improved a lot, there are still a lot of nVidia adapters for which nouveau fails to provide any useful graphics screens. For new users, the failure to boot to a meaningful display is frustrating. The problem used to affect only persons that had implemented the proprietary closed-source drivers, and their graphics failed when the kernel changed. They could be warned in advance because a lot of them came to the forums for help in getting the propriety driver installed. With KMS, people are having trouble with their initial look at an openSUSE version. I expect many decide that openSUSE is flawed and move on to other distros.
I propose two fixes/workarounds:
(1) Make the GRUB option "nomodeset" be the default for all installation media. There will be very little impact on the NET install CD or the DVD install disks. The lower graphics performance for the Live CDs will be a small penalty to pay for the benefit of getting a great many more systems to boot. If the "nomodeset" appears after the "VGA=" on the GRUB options line, it will be easy to advise people to try removing it when booting. They will quickly learn if they need it or not.
(2) In the installation process for GRUB, detect the presence of an nVidia adapter and pop-up a screen advising the user that the installed system may need the nomodeset option in order to boot. I single out nVidia because nouveau seems to handle many fewer models than the KMS drivers for the others. I don't have any ATI adapters, and the one i915 system I have boots without trouble. One of my nVidia-equipped systems boots to a blank screen with nouveau, and the other corrupts the alternate terminals.
I have no doubt that the KMS developers will have drivers that handle nearly all adapters in the near future. As someone having experience with reverse engineering, I'm really impressed with the progress, but kernels 3.0 and 3.1 still need some work. As we can help our users get a more satisfactory experience with quite small changes, I think we should do so.
Thanks,
Larry
It's not just nvidia. I have boxes with integrated intel video that crash (not merely no dislay or bad display) without "i915.modeset=0". Luckily the box was already known to work fine on earlier kernels and it wasn't a fresh install on unknown new hardware. So just by that good luck I DIDN'T waste a lot of time thinking I had bad ram or any other hardware problem that would normally be the far more likely thing to suspect before you start thinking maybe this big professional distro was broken. I never actually tried "nomodeset" on that box yet, I hastily googled, found i915.modeset=0, it worked, and the box has been running since then. So if "nomodeset" will end up doing the same thing, then I'm with you all the way. Crash, or anything else even a little unexpected, on boot, when the hardware isn't actually bad, when there exists a known more robust option, from the default installer or livecd, or the setup created by default, is pretty bad. What bugged me about that episode is the same thing that has always bugged me about opensuse on all my boxes, which is that I don't feel that I should even have to worry about possible graphics card problems when I don't even use the vga port at all. All my boxes are serial console. The bios sets up serial console, I choose "minimal text/only system" during install, grub has "console=ttyS0,115200n8r" Yet I still have to fight the installer to keep the dreaded gfxboot message file declaration out of menu.lst. It puts a message file line in there no matter that I clearly selected "text-only system" and no matter what I put in, or don't put in, the message file field in the bootloader screen, even if I use the advanced menu option to edit menu.lst directly to remove it. Only way is to do it outside of yast on another ssh session after yast writes the bootloader files but before the reboot. I have to manually search, remove and taboo all the gfxboot, splash, and branding packages every time. So, keeping with the pattern above, I very much disliked having yet another thing appear out of nowhere and start trying to futz with the video card without being asked, and not only screw up my console which was bad enough, really that's inexcusable already, but now actually crash the box during boot? When I didn't go out of my way to ask for it? This isn't about "gee, some new software was buggy? so what? that's unavoidable dummy. welcome to computers." or "that's what the failsafe boot option is for". This is about procedure and totally unnecessary, un asked for, artificially created, actively inflicted problems, due as far as I can see to loss of standards. This particular bug is in a new feature that wasn't asked for and whose purpose is merely the luxuries of increased video performance and fancy graphical display modes on a _text_ console. If the latest kernel had some bug in one of the more basic subsystems, well you can't help that. That can happen any time. You can help the fact that you know these graphics modes don't work everywhere for many reasons: * video card driver support * serial / net consoles * monitors / kvms / ip-kvms that can't handle the modes even if the video card and drivers can and even if they think the display can from dpms. If they don't work everywhere, then they have no business being default and they _certainly_ have no business being so hard to eradicate even when the admin knows he needs to override the defaults. Even if it's the default it should at least be a given that when the installer chooses "text-only system" they get a text-only system. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org