With KMS, the graphics drivers are moved into the kernel. Since the framebuffer was already in the kernel, I wouldn't expect this to affect framebuffer operation. Yet, I read that KMS supercedes the fb, augments the fb, requires the fb, and requires fb support to be removed. What the heck? The answer I'm looking for is an explanation of the relationship between KMS and the framebuffer.

I have been using uvesafb to get native resolution at the tty. My purpose here is to understand how that is going to work on a system with KMS. It would also help to cover things like.. Is scrolling faster with KMS? Do utilities like fbterm and fbida work the same? Is stability better?

2 Answers 2


First of all, there are basically two types of classic framebuffer drivers:

  • Generic hardware & firmware drivers (e.g. vga, vesafb/uvesafb, efifb)
  • Hardware-specific drivers (e.g. intelfb, rivafb, atyfb)

The classic framebuffer drivers all had basic modesetting support, but they exposed little if any support for hardware accelleration.

With the classic X design, this wasn't really an issue: to get 2D acceleration, the X server ran as root, and could access the hardware directly. It basically bypassed the framebuffer driver completely. For 3d (and 2d support on newer cards), it would also use a kernel DRM driver that mediated access and managed video memory.

In this setup, there were two places where modesetting was done: both in the kernel framebuffer driver, and in the userspace X server. This duplication of code (and occasional fighting between drivers, e.g. on VT-switch) was not ideal.

In addition, there were two separate drivers in the kernel for the same piece of hardware: the framebuffer driver and the DRM driver. If you were using a hardware-specific framebuffer driver (e.g. intelfb), you could load either the framebuffer driver or the DRM driver, but not both at the same time.

KMS was the solution to these issues. It:

  • Merges the kernel hardware-specific framebuffer driver and drm driver into a single driver.
  • Provides an interface for the X server, Wayland compositor, or other application to use to control modesetting, so the userspace application doesn't have to directly access hardware. (Indeed, with KMS, an X server no longer needs root permissions.)

Some interesting notes: The migration to what is now KMS actually started around 2004; see Jon Smirl's email on console rearchitecture.

To answer your more specific questions:

  • Speed generally won't be worse than one of the unaccelerated generic drivers (e.g. VGA, vesafb), but the KMS framebuffer text console was designed for convenience and emergency use rather than speed, and the console isn't fully accelerated on some drivers. Wrapped long lines are pretty bad on intel cards, for example.
  • Applications designed to use the old framebuffer interfaces will still work on a KMS framebuffer.

KMS sets display resolution and depth in the kernel space rather than user space. So yes it supersedes it. It enables native resolution in the framebuffer.

Kernel Mode Setting

  • 5
    Wiki articles about KMS are easy to find, but the explanations are terrible. How can KMS supersede the fb and at the same time enable it? The fb already supported native resolution, so what is different? Do fb utilities work with KMS?
    – user5184
    Jun 28, 2011 at 15:29
  • i don't think framebuffer support native resolution, especially when the monitor is widescreen. for example, native resolution of my LCD monitor is 1680x1050, however, framebuffer only detect 1280x1024 resolution Oct 28, 2012 at 9:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .