Graphics cards from different manufacturers are very different beasts, in fact, often different generations of graphics cards from the same manufacturer can be pretty different too. While there’s a great deal of standardisation for things such as resolutions, colour depths and talking to monitors; the software side has almost no standardisation whatsoever.
In fact, one of the most fundamental operations, setting the resolution and color depth we desire (aka. the Mode) can be different for each and every card, let alone each and every manufacturer.
Practically speaking, this means that there are only two things that know how to set the mode. The Video BIOS and the Graphics Driver. Historically, within Linux, the Graphics Driver has resided within the X Window System server.
There are lots of different places that we need to set the mode:
- during boot, the Video BIOS will set an initial mode
- this may be changed by the boot loader using the Video BIOS or VBE
- when the X server is started, it will likely set a new accelerated mode using the card’s native protocols rather than VESA
- when switching between away from the X server to another VT, the previous video mode has to be restored
- when switching back to the X server from another VT, the correct video mode has to be set
- when resuming from suspend or hibernate, the correct video mode for whatever VT we resume to has to be restored
The two biggest problems here are switching from/to the X server VT, and resuming from suspend. In the former case, the biggest difficulty is actually switching between X servers on different VTs (e.g. user switching). The process ends up looking like this:
- user switch initiates VT switch from X server on VT7 to X server on VT8
- X server on VT7 restores the previous video mode (likely VGA text)
- X server on VT8 sets the video mode appropriately
This leads to the black screen and flashing cursor between VT switches that everybody hates. In the resuming from suspend case, it’s really tricky; we don’t necessarily know the right video mode to restore, calling into the Video BIOS (even with VBE) is tricky, error-prone and doesn’t work if it wasn’t a VESA mode, and the X server’s mode setting code was never designed to be called externally. This means we used to basically rely on resuming into the X server and having that restore the mode for us.
All this changes with Kernel Mode Setting (KMS). Throughout the development of Lucid, you’ve probably seen that term mentioned a few times.
Simply put, Kernel Mode Setting is all about taking the bulk of the Graphics Driver code out of the X server and putting it into the Kernel. This means that the kernel has Graphics Drivers just like the kernel has Network Card Drivers, Wireless Drivers, USB Drivers, etc.
Most importantly, the kernel can set the mode whenever we need to and restore it on resume. The three most user-visible results of this are:
- a high-color, high-resolution splash screen during boot with a seamless (no black screen) transition into the X server
- fast and seamless transition between X servers when user switching
- extraordinarily fast resume from suspend directly into graphics (no blinking text cursor)
Behind the scenes there’s even more awesome waiting to be used in future releases.
Obviously most of the effort on writing these new drivers has gone to the “big three” graphics card vendors’ hardware. Intel themselves have contributed a large part of the KMS work, and their own drivers for it; nVidia owners are covered by the reverse-engineering effort that created the nouveau driver; and ATI owners are covered by the new radeon driver.
Those with graphics cards from other vendors are a little out in the cold here, but at least they’re no worse off than they were before. The biggest source of complaint comes from those with cards for which there is also a binary driver available (usually nVidia).
By switching from the in-kernel graphics driver (i.e. nouveau) to one supplied as a binary loaded into your X server (i.e. nvidia-glx), you will not have Kernel Mode Setting support and are effectively regressing your own system to Ubuntu 9.04 state.
I’m sure that nVidia users will be quick to point out that in Ubuntu 9.04, they had more than 16-colors for the splash screen, and that’s true.
One of the other changes made in 10.04 is the switch from using usplash to draw the splash screen to using Plymouth. Both had the ability to draw to frame buffers (basically kernel 2D graphics canvases), but Plymouth had much better support for multiple heads, native panel resolutions, and most importantly the smooth transition into X.
Supporting KMS properly for those using the open source drivers meant regressing slightly in prettyness for those who don’t.
usplash used to support higher colors and resolutions by using SVGAlib as a backend when a frame buffer was not available; writing a new Plymouth SVGAlib renderer was simply too much work on top of the existing integration worked that needed to happen for KMS. (If someone wanted to do it as a personal project though, go right ahead!)
An alternative to using SVGAlib would have been to at least set a better mode through VESA or VBE. There are two common ways to do this, firstly by using the VESA frame buffer (vesafb) or secondly by having the boot loader set the graphics mode and keep it set when running the kernel, triggering the use of the EFI frame buffer (efifb). The problem with both of these is resuming from suspend. As discussed in detail above, we don’t have the ability to restore this mode on resume.
So we picked the third alternative, which has the added attraction that it works on all hardware and doesn’t cause other issues. We use good, old, reliable 16-color VGA.
nice topic Scott, thanks
keep it simple and effective
so those of us with KMS-supporting drivers + cards, can we get >16-colour virtual terminals in lucid+1? that’d be great for ubuntu-server + byobu
Another big KMS feature is that it opens a path for alternatives to the X server. We’ve been using X for 25 years because it was incredibly painful to develop an alternative. With KMS and Mesa this basic code is now in a common library and things like Wayland can be built with a reasonable effort.
Yes, it will lead to a simplified X.org that is more crash resistant and can run in user mode (more secure).
Pingback: Links 31/3/2010: KDE Software Compilation 4.4.2, New GNOME Journal | Techrights
Is there technical reasons the nvidia proprietary drivers couldn’t be included in the kernel? I guess they are blobs, for one, and there are certainly licences issues, but would it be technically feasible?
Is there any hope for nvidia binary drivers supporting kms? It’s all well and nice to have open source drivers but really they are severely limited when compared to nvidia’s own.
Pingback: GoblinX Project » GoblinX Newsletter, Issue 244 (04/04/2010)
And, what anbout this workaround????
http://ubuntuforums.org/showthread.php?t=1446132
I have a little trouble understanding all the upbeat thinking about KMS and Plymouth in particular.
The fact is, its a flipping disaster for a good half of Ubuntu users and it will stay that way.
I think Scott posted on the Ubuntu Forum to the effect users would be able to enjoy watching the boot messages again (because Plymouth doesnt work). Im happy to be corrected on that but Ive read it again tonight.
Hey guys Im sorry but this is a major step backwards for Ubuntu and for Linux as well. Please compare this to the boot experience provided by Apple or by Microsoft. Tha latter is the minimum people expect.
Enough said anyhow, Im just disappointed that stubbornness has won the day.
darkhole: that “workaround” is exactly what I was referring to in my post when I said there was an option of “having the boot loader set the graphics mode and keep it set when running the kernel, triggering the use of the EFI frame buffer (efifb)”.
This has the same problem I described; the efifb driver is not able to set the video mode, so on resume from suspend, there is no way to restore the console video mode you had when booting – and that the framebuffer expects to have.
Also we then have to rely on the graphics driver in the X server to set and restore the mode on switching to/from X – and thus ugly transitions when switching between X servers.
katie-xx: I think you’ve missed the entire point of my post. Moving the graphics drivers into the kernel is a great thing for those graphics drivers we can do it for, for those we can’t there is no change in behaviour other than the boot splash.
We’d rather have the features the new drivers will give us than a pretty boot splash for those using proprietary drivers.
Also, frankly, the number of bug reports I have received do not support your assertion that a “good half of Ubuntu users” are having problems. At this point, I would say that a small minority of users are having genuine problems, and we expect to fix those before release.
OK ..I will take your word for it
The position at the moment is if you have an ATI card you are treated to a nice blinking cursor. If you have a NVidia card you might have one of several different problems but notably the plymouthd has crashed dialog. .. Both have been reported numerous times to my certain knowledge and I would postulate a good half of Ubuntu users have NVidia or ATI kit.
That may change with the advent of Windows 7 more people are buying new kit and probably Intel graphics are making headway in the market because of that.
By the way …. tel me how you do it
There is just no way I could work with that Launchpad mess. How on earth do you manage to sort out the wheat from the chaff?
Thanks
Kate
Pingback: Ubuntu 10.04 lucid のグラフィックドライバ（と Plymouth） « Kawaji's Weblog
Having only 16 colors in splash screen is not very critical regression. Bigger regression is that I can’t use all the video modes I could by 9.10 (and 9.04) in X. Even some of the listed modes are invalid. Another big regression is that it can’t resume from suspend to RAM.
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/567319
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/568310
Pingback: [Lucid][Ubuntu 10.04] High resolution Plymouth & Virtual Terminal for ATI/NVIDIA cards with proprietary/restricted driver « Tux’s idyllic life.
Hi, i found this post. It Works perfectly for me with ATI mobility radeon HD 3450 at 1024×768-24
http://idyllictux.wordpress.com/2010/04/26/lucidubuntu-10-04-high-resolution-plymouth-virtual-terminal-for-atinvidia-cards-with-proprietaryrestricted-driver/
Hope it helps, is not mine, i just paste it.
Thanks Scott
I was wondering about this and had a plan to use one of the fixes. Now I know not to
I’m I right to understand, that the only way to make it work properly, is by writing a new Plymouth SVGAlib? And if so, is that planed for 10.10?
Pingback: Ubuntu Will Switch to a User Mode X Server | Ubuntu Switching to Rootless X Server
Hi, thanks for your brilliant work.
A long standing full time Ubuntu sufferer.
Toshiba A80 with Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Trying to make a long story short. Sorry for that.
Dapper: working fine, including suspend to RAM.
Jaunty: had to revert to 2.4 driver during the whole release.
Karmic (whole release): could not use suspend to RAM (black screen soon after resuming)
Lucid: the same. Sometimes, when black screen occurs, possibility to switch to “degraded mode” (no Compiz)
modeset=1 has been written on an /etc/ file for whatever it means…
I reported to Launchpad. I read everywhere: fix released. Is it a chronic malediction?..Can you advise me something useful?
Very nice article Scott. Thank you!
I’m not competent to follow all your justifications for
the way Lucid Plymouth works with some hardware, but for my old SiS video, installing v86d (via Synaptic) makes Lucid boot-up a lot better looking affair than the way it looked originally. See my comments on Bug 584339.
Should I care if I only have a 16bit experience before the log-in screen? It beats a black, un-informative screen. yeti
in other words: open source drivers are a big win. ppl shouldn’t see nvidia/fglrx drivers are “addons” but rather as “deprecated”
s/drivers are/drivers as/
Pingback: Blog-Nya Rantarou » Ubuntu 10.04 High Res Plymouth+Virtual Terminal for ATI/NVIDIA with propertiary Driver
When I first upgrade to Fedora 12, it totally shocked me because I got a text console in native 1680×1050 resolution. It looks very well, no more paging, no more
morein most operation.Wish Redhat/CentOS has the up-to-date kernel quickly……
期待红帽/CentOS尽快加入最新的 kernel……