The kernel doesn't ignore it. Before KMS kicks in, vga=normal. Once KMS kicks in, a new driver takes over and this new driver takes different options. If you don't like that, take it up with the kernel folks.

Adam

0 members found this post helpful.

You might think that this is a trivial issue but I am sure that I am not the only 13.37 user who has a problem with this fundamental bug.

Which doesn't change the fact that you should bug the kernel developers about this if you really don't like how KMS works (BTW, disliking how something works doesn't automatically make it a 'bug').

The most Slackware could do is warn users about the fact that with an nvidia, intel, or radeon GPU, their console resolution is going to change as soon as KMS kicks in.

Adam

I'm happy to have found a reason for the grievances I have had. One machine, on which I installed Slackware, quite simply went gave the monitor three blurry images to show.

How about completely disable this KMS if oldstyle, normal or classic mode was chosen during install?

Disabling modesetting will break X on radeon and intel GPUs. I could see, however, also setting video=640x480 if vga=normal is selected during the lilo installation.

Adam

I've got it disabled on my laptop because, as I mentioned before, that's the only way to get it to resume from suspend or hibernate. X works fine, as long as desktop effects in KDE are disabled. 3D doesn't work at all. The kernel in /testing doesn't help. Worked fine with the presumably pre-KMS kernel in 13.1. At this point it's a choice between what part of the driver you want broken more than another. I chose breaking 3D over breaking suspend/resume.

If I get bored/go insane I might try compiling 2.6.39 and see if that makes anything any better. There's a ton and a half of Radeon KMS changes in there.

I am marking this thread as solved. I still can't believe that KMS overriding the "vga=normal" parameter was done deliberately. It goes against all good programming practice to change the way a command works - especially when no warning is given.

I solved my problem by re-installing the 2.6.33 kernel from Slackware 3.1 and also the 2.6.38 Kernel from "testing" and made all three kernels available via lilo.

The 2.6.33 kernel still works and my SO advises me that file access speeds are much the same as before. (Phew! I don't have to downgrade back to 3.1 after all).

The 2.6.38 kernel handles the transition from CLI to GUI much more smoothly than the 2.6.37 kernel does and file access speeds seem to be the same for all three kernels.

So, it looks like the 2.6.38 kernel is the way to go.

I want to thank everyone in this thread. I'm running a total basic Slackware (no x) to learn Linux/U**x, and it's really a great tool for the purpose.
I nearly gave it up due to crouching close to my tiny-screened netbook.
No crouching, squinting now!
Thanks again, all.