Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

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

share|improve this answer
2  
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 '11 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 –  LiuYan 刘研 Oct 28 '12 at 9:34

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. 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. In some cases (e.g. pre-kms intelfb), you could load one or the other, 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 to use to control modesetting, so the X server doesn't have to directly access hardware. (Indeed, with KMS, the 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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.