From Fedora Project Wiki

< Features

Revision as of 19:52, 12 August 2008 by Ajax (talk | contribs) (text! beautiful text!)

Kernel Modesetting and Memory Management


Currently, most graphics modes are initialized during the X server startup. Kernel Modesetting (referred to as KMS hereafter) moves this process from the X server's DDX drivers to the kernel, and it enables several new features including:

Memory Management, while a separate feature in its own right, is included here because it is a requirement for Kernel Modesetting.


  • Name: DaveAirlie, AdamJackson

Current status

  • Targeted release: Fedora 10
  • Last updated: 2008-08-08
  • Percentage of completion: 35%

Detailed Description

With KMS, output setup services move from being the job of the 2D X driver, to being the job of a kernel driver. Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode. Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session.

With KMS, a simple default policy is loaded into the kernel for initial output setup, which means connected displays should go to their native resolution as early as possible. Graphical display services, like the X server and the new Plymouth boot manager, simply reuse the existing display settings if they match what is desired. This allows for a seamless transition between bootup and login screen. Fast user switching can also take advantage of this; if both users have the same screen resolutions, then there's no need to blink to transition, and even if they're different, the kernel can make the switch exactly once (instead of twice like before).

Finally, since the kernel is aware of which regions of video memory are being displayed, it can print panic messages to the display, which will assist with troubleshooting.

Benefit to Fedora

Graphical panic messages allow kernel developers to collect information about crashes and lockups that happen while graphics are active. Historically, this kind of bug was difficult to diagnose, because the panic message would effectively not be printed anywhere. While it was possible to collect this kind of crash data with network or serial consoles, it wasn't trivial for a user to set up.

The enhanced graphical startup and user switching experience makes Fedora feel more like a polished, professional product. It's eyecandy, but it's such delicious eyecandy!


KMS requires per-driver kernel support. The initial targets are ATI and Intel graphics chips, as sufficient documentation exists to implement kernel drivers for them. The design of the kernel's KMS API is still in flux, and interacts with any kernel video memory management subsystems that may be in play (GEM, TTM, etc.). Plymouth, and the corresponding 2D X drivers, also need to be updated to use the new KMS APIs when they are available.

Test Plan

KMS is highly hardware dependent. At least the following configurations need to be tested:

  • Intel 915/945
  • Intel 965 and above
  • Intel 865 and below
  • Radeon R500 and above (ie, ATOM BIOS enabled)
  • Radeon R400 and below (ie, not ATOM)
  • Everything else

Plymouth testing is expected to be described on Features/BetterStartup. For each of the above configurations, plymouth should do the expected thing, whatever that is: either graphical splash if KMS support lands for that hardware profile, or text splash if not.

For each configuration, X startup and shutdown needs to work as expected, both when plymouth is enabled and when it is disabled. Additionally, fast user switching must be tested and working.

Graphical panic support will likely get tested "for free", since it's hard not to accidentally panic at least once while developing the appropriate kernel code. However, manual testing can be achieved by starting X and then echo 1 > /proc/sys/kernel/panic as root.

User Experience

For KMS-enabled hardware, the user should spend much less time watching their monitor blink while the system starts up. Fast user switching will be faster and smoother, making Fedora more pleasant for non-technical and casual users.


Plymouth and the X server will both consume the KMS services provided by the kernel. Plymouth really does not want to be in the business of having multiple drivers, so a consistent API between kernel drivers is desirable.

Contingency Plan

If kernel modesetting is not present, user modesetting is performed by the appropriate X server DDX driver as in past releases.


Related links:

Release Notes

Probably. If it's possible to disable KMS support for a DRM driver, that information should go here.