From Fedora Project Wiki

< Features

Revision as of 07:41, 22 February 2009 by Mattflaschen (talk | contribs) (→‎Test Plan: see talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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-10-24
  • Percentage of completion: 100%

Details: The infrastructure is all in place. The driver details are as follows: For AMD/ATI hardware, R300 and newer has KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so is default to disabled (this has been targeted for Fedora 11). For Intel hardware, we default to disabled (targeted for Fedora 11).

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.

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

Kernel modesetting can default to either enabled or disabled in the DRM driver, and it can be enabled or disabled at boot-time. Both Plymouth and the DDX drivers will detect whether KMS is present and enabled, and if both present and enabled, they will take advantage of them. If either KMS is not present or it is present but disabled, then Plymouth will automatically fall back to the text splash and the DDX driver will automatically fall back to user-space modesetting (as in past releases).


Related links:

Release Notes

We will need to document how to enable/disable a driver at boot-time and will need to document any known bugs or performance issues.

Workarounds/Boot Parameters:

Kernel Command Line Options:

Holding down ctrl to access grub the following can be used to modify the KMS behaviour. These can also be added to /boot/grub/grub.conf

All drivers: nomodeset - this will disable the kernel modesetting feature and drop the user back to the old infrastructure and behaviour.

Radeon specific:

radeon.agpmode=x where x is -1 = Enable PCI mode on the GPU, disable all AGP. 1, 2, 4, 8 = Enable AGP speed.

This option replaces the old xorg.conf options, AGPMode and Option "BusType" "PCI", if you had to specify these in the past to get DRI or X working then you need to specify them on the kernel command line.